You cannot get a BWindow* that points into another application because each application has its own memory space and pointers just don’t work that way. However, using the scripting interface, you can easily enumerate another app’s windows, and instanciate a BMessenger to communicate with them. The “scripting suites” are documented in the Be Book (but a bit briefly): The Be Book - Classes And Methods - The Application Kit
This is available in the menu of Installer or by runningthe “bootman” command in Terminal.
… is this the thread where people request already existing features?
The problem I see with BApplication::WindowAt is that it doesn’t take the order of the windows into account, at all. If one window overlaps another, then the window that was created first will come first in the list, not the window that’s actually on top. There’s no other way to determine the stacking order of windows either, so applications cannot sort the window list manually.
As for windows created by other teams, it isn’t vital to get a BWindow object for those. Some special value accompanied by their frames should be sufficient.
Only small question i have usb wifi key with realtek chipset its some tp link tl-wn723n inthink is version 2, for beta4 i vote for more usb wifi support, small improv. hide/show password ui, and maybe support for ssb manager for create bookmarks of web apps like peppermint linux or linux mint have.
I feel like you should be able to track the z order of windows through the WindowActivated() callback. The windows could send messages to the BApplication when they are activated and un-activated and their z order could be tracked there. Maybe not quite as handy as asking app_server but I feel like this would work.
That doesn’t work if your window has some unusual stacking rules, i.e. B_AVOID_FRONT, where its stacking order can change among other B_AVOID_FRONT windows, but not necessarily upon activation.
Would love to see the Deskbar UI/UX get back to the same general flexibility as that of BeOS. I’m mostly talking about the Applications, Preferences, etc. and the Tracker prefs you can’t set. I realize those blue folders are queries, but we should be able to get icon views for those and we should be able to persist the Tracker prefs. Also, it would be nice to bring back the iconic folders for those.
I agree with you about Deskbar even if it had just manila folders again that would be an improvement. We’re waiting on a long planned better interface to organize your Deskbar applications into categories.
As a Mac OS X guy but not a classic Mac OS or BeOS guy or especially not a Linux guy I would prefer the Applications menu item to simply open up your applications folder and let you organize that folder any way you want in Tracker. Unfortunately that’s never going to happen so it stays as is.
For me personally Tracker thumbnails was my Beta4 goal and we seem to basically be there now.
Basically, it wouldn’t be a big problem to organize that, because if you would define categories in the Haiku menu guidelines (e.g. Office, Media, Internet, Network, Graphic…) and would then also demand these from the packagers.
So far, if at all, it is often forgotten, that the developers put the links to applications in the menu folder provided for this purpose. However, everyone can include subfolders in their package, which are then visible in Applications. Some already do this, although it is not required by the system. Ultimately, that would only be nice if it were anchored in the menu guidelines.
Ultimately, the packager has the same freedom as under BeOS. Only nobody does it.
I would also like a menu folder for Games next to Applications
It would also be nice to have an application like my HPKG Creator (for external packages) to use for HaikuPorts recipes.
If it’s helpful to include this in my program, I’m open to suggestions, just need someone to help me as I have no experience with the HaikuPorts recipes.
I’d say for the wishlist: more drivers. There’s already a compatibility layer for FreeBSD (and OpenBSD) WiFi drivers, which helps.
But maybe a small course for wannabe driver devs would help the development of native drivers.
Or some sort of compatibility layer (ReactOS inspired?) to use windows drivers?
More drivers will be a huge factor in the amount of Haiku users (and hopefully developers).
Just checked out a basic font recipe I did a short time ago, compared to just creating a recipe it’s a ‘bit’ more work, and you’d need pre-compiled sources, took me bit of figuring out how it works, some keyboard shortcuts would be handy (like creating the layout for the directories …)
I think stingent categories are a mistake for menus, users should not be forced to have their menu organized in hierarcies depending on packagers guidelines. KDE for example does this and it works terrible.
What we could do is add a tagging mechanism with extended attributes and make tracker use it, that way we have a flexible system that users can easily modify, and can have applications appear in severall places based on what the user cares about to have.
Nothing happens by waiting. No one is currently working on it so it won’t happen until someone does.
They are not, they are text files with a hack in Tracker to pretend they are folders.
But, if you want to manage DeskBar manually, you can simply delete the “blue folders” and put your own folders in place. The only downside is that applications installed from HaikuDepot won’t automatically be added to the DeskBar if you do that.
Why not? That’s how it used to work before the “blue folders” nightmare. And everyone hates the blue folders, no one wants them to stay. It just needs someone with nothing more important to do, so they can spend some time on creating something else.
It depends what the categories are. I think applications/games/preferences (and maybe we can keep the existing demos/desktop applets?) is not really a problem. The problem in Linux is they do way too small categories and deep levels of hierarchies, which means each app is in one of 3 or 4 reasonable places.
Someone who has installed many applications and has tried a lot will quickly notice that a single directory for the applications in the menu is not enough.
original menu
The possibility of having your own menu tree through manual maintenance was a good idea, but as you have already written, subsequently installed programs are not automatically inserted.
A solution would be interesting in which newly installed programs/games would automatically end up in Applications if the original menu path was changed (now physical folder, before imaginary folder).
Then you can update the menu with menu sorting programs if you want and can still use the newly installed software immediately.
It’s not a query, it’s a text file with a list of paths to other folders. Try this:
cat /boot/system/data/deskbar/menu_entries
to see the content of it. It is a merge of 5 directories, of which 2 are packaged and 3 are user-writable.
The “edit in tracker” button in DeskBar preferences allows you to easily reach one of the user-writable ones so you can add your custom DeskBar entries there.
Then DeskBar and Tracker read that file, and read the content of the listed folders, and attempt to merge them together.
In Tracker this reuses the same code used to display query results, but that’s the only thing it has in common with queries.
There was a proposal to use queries instead, which would possibly be simpler: have the deskbar menu entries be queries stored in a writable directory. Then if you don’t like them, you can replace them. That would be a lot simpler, I think? I don’t know why this was never finalized and merged. It will however require all haikuports packages to be updated to this new scheme:
Remove the symlink currently used to fill the menu
Instead add an attribute to each application to say “I want to be in the DeskBar Application menu”
The more we wait and don’t do this, the more packages we have to fix.
It is a bit ridiculous that everyone complains about the blue folders and hate them, yet no one has finalized this much better and simpler solution. I am very confused about this.
It will however not fix one of the problems: currently it is not possible to show a query in icon mode in Tracker and organize the icons. Only list mode will be available still. But at least we can remove the “blue folders” that no one understands, and finally we have a real use for queries
And we can see about how to support icon mode for queries. It is not so simple but it should be possible?
I’ll look at my current setup, but I think I ended up symlinking the menu entries in order to do away with the blue folders, get the supported icon mode, though it doesn’t persist and still take advantage of the ever evolving list of applications, etc. keeping them in sync automagically.
Now if you could get the folder icons back in place and persist Tracker settings, the solution is as good as BeOS if not better in some ways and would definitely be better than the current solution.
I don’t know if we even need to update HaikuPorts recipes. Some rather deliberately create subfolders, and I think we should keep that? Instead the folder itself should get the query attribute.
mmu_man has an old change towards this. However it doesn’t actually set a “show in deskbar” attribute, it doesn’t handle folders, and it also probably won’t work so well for the majority of applications whose category is haiku-apps… so indeed more work is needed.
I guess if nobody else wants to tackle it, maybe it falls to me by default
and still take advantage of the ever evolving list of applications, etc. keeping them in sync automagically.