[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] XaAES



Helmut Karlowski skreiv:

N.AES simply started the program pointed to by RSMASTER. XaAES and

You mean an environment-variable? Well I would rather like this to reside in a defined directory similar to XaAES, and the xfs, etc. So its easier to configure and one can be sure to run the correct version.

As long as the resolution-changer can be started as a normal application, it doesn't matter how XaAES finds it. The user can still set the RSMASTER variable, and the desktop can still use it.

Teradesk could do the same, both saving some bytes. Then it would be easy to support all sorts of hardware, "just" write a new resolution-change-app.

Yep - somehow we are missing some manpower ...

I can write the app(s) if someone can help me with the resolution changing code. I don't know anything about that.

MagiC only have the WDialog listbox, which is "only" a listbox. It

Do you know of any programs using these MagiC-lists? If there are no, I think we could ignore MagiC.

I'm not sure what you mean. I guess there are several apps out there that use the WDialog listbox, but as XaAES already supports this you don't have to care about compatibility at all. Just create a better solution (G_SLIST) in addition to the WDialog features.

Yes, the idea is that the previously topped application always is the first in the list when switching using alt-ctrl-tab. This is how it

Ah, yes, the windows-method, of course. I use this myself quite often, should have known this. So you have to rearrange the list, something like a stack, but thats not my businuess :)

If Taskbar can use this hotkey (Alt-Tab, or Control-Alt-Tab) I can easily enable this code again. It's more than 10 years old and could use some cleaning up, but that will just be fun.

Perhaps a general, user-configurable hotkey-solution would be nice? Something like...

hotkey TAB "TASKBAR "
hotkey d "xaessnap"

...in xaaes.cnf? The applications the user set up like this would receive the specified key when used together with Control+Alt, even when it doesn't have keyboard focus. This will require no special API at all on the client side, and the user will have full control as the clients can't grab hotkeys automatically.

menu. This is enough for the start. Then one could install taskbar to get more comfort. Does it run without a desktop? I started it without teradesk and nothing seemed to happen.

Taskbar needs an AV-server to do it's stuff. Without an AV-server installed, it will exit quietly after 10 seconds.

Well, I probably shouldn't say this (in case of failure!), but this is one of the things I'm working on now. Some sort of GEMified top with a treeview and a couple of graphs showing CPU and RAM usage.

How can this fail?

For many reasons, most of them being related to the fact that I now have a wife, two kids, a house, a garden and a proper job ;-) It's not like 10 years ago when I only had myself, my Falcon and my motorcycle to care about.

I would wait until the list-window-feature of XaAES is exported, though, so there is a practical target for the

I have already written most of this. I have some general list/tree-code that allows me to read the data and shuffle it around, then I build the resource-tree at display-time. This makes it "easy" to present data in various manners.

implementation. I would also like an additional headline for each list that names the columns, and by click you can define the sorting, and probably resize the columns (well, like windows again).

Columns doesn't fit the idea of a tree very well, but it's something that I plan to use in another project. I have been considering using an interface somewhat similar to the Windows file explorer. The process-tree is displayed to the left, and when you select an object in this tree, details about this object is displayed in a panel to the right. It's nothing fancy, just a visualization of /kern.

Unless gcc gives me a stroke that is.

I recommend to install cygwin: Its a real pleasure to run gcc now. The files are compiled in the same time, the atari would need to just touch them!

I still prefer PureC, and will almost certainly continue to use it for my project. Taskbar consists of around 200Kb of source, which PureC comppiles in a few seconds. When working with one or two files, turnaround time is just a couple of seconds. There is no way gcc can compete with that.

Jo Even