Rather simple: emerge blackbox -> My menu is lost.. Now I have the standard Menu and have to recreate my own.. This build should protect it's config-files, I think.
um, actually, if you create your own, you should put it in ~/.blackbox/menu and then source the /usr/share/commonbox/Menu file from that.
uhm, actually that doesn't change the fact that my system-wide defaults are lost. Don't want to cry about that, I just don't think this is the way it _should_ be?
I wonder why you changed this to wontfix? If you tell me to source the system-wide menu-file (I did that) and I tell you that this file will get lost with emerging blackbox? I don't think that this makes sense. System-wide menu-definitions should be in this file. Of course I could create a menu2-file in that directory and source only that, but that's not the way it should be. Perhaps the blackbox ebuild should install its menu-file as menu.sample? I hope I get a response in spite of posting to a "RESOLVED WONTFIX"-Bug..
ok, wait, I just saw your response to my response. can you give me an example?
Sure. I'm using Blackbox on my Gentoo-box for several Users. I confgiured the system-wide menu in the file /usr/share/commonbox/Menu with the defaults for every User (some applications every user uses like terms, browser, etc.) and every user has a Menu in ~/.blackbox/ that sources the original file and extends it with user-specific programs. Some use icq, some sound-processing tools and some (me) want to develop and play ;-) If this is a totally wrong way to archieve this: Please tell me how I'm supposed to do this instead. Right now it's kind of the "startmenu" of WinNT/2k: You have the systemwide-menu and the usermenu. This configuration won't work if any new bb-release kills my global menu-file. Furthermore I'd like to know what this global file is for, if it's going to be overwritten? It should be a sample file (No need to keep the old file then) or a config-file (And therefore it shouldn't get lost). Just my thoughts. And thanks for reopening/listening to me.
Thats a good point. we should consider moving the {black,open,flux}box menus from /usr/share to /etc/commonbox-menu
There are a few possible ways this can be handled: -) Move the menu to /etc/commonbox/menu (or something similar). That moves it into the realm of etc-update territory -) Prevent {Flux|Black|Open}box [the boxes] from installing a default menu, as commonbox installs it's own common menu. The commonbox menu could be renamed to menu.sample so as not to overwrite any currently existing menu. This presents the problem that on a clean install, no system menu will be available at all (becuase the fesh one is menu.sample, and the boxes will be looking for menu). This could be handled with some messages in a pkg_postinst() or by some other means I guess. -) In userland, I can think of two ways you can prevent this on your own. Add /usr/share/commonbox to CONFIG_PROTECT, which may seem dramatic, but if your system is heavily using any of the boxes it could be used as a measure to protect *all* you current settings, not just the default menu. The other is what was mentioned before: Create a menu-systemdefaults file, and source that in as your default system menu. Me thinks it strange that that would be considered a wrong thing to do. I think that's just called tweaking/customizing/personalizing. Interestingly enough this exact same thing happens to vim, but I never hear anyone complain about it. Every emerge of a new vim overwrites /usr/share/vim/vimrc and I lose my syntax highlighting.
It's been a week without comments. As it stands, I'm inclined to currently leave the setup AS IS. I still do not hold the opinion that sourceing something other then '/usr/share/commonbox/menu' is the "wrong" thing to do, so making a copy and sourceing that seems completely fine to me. This, however, does NOT mean by any means that I have stoped thinking about this. I have plans to make some changes to the system default menu and will be looking at different aspects of it. I'll leave this open for comments for up to another week.
Sorry, I got a new Job this week so I'm quite busy atm. I have no problems with copying the file and sourcing another one, but I'd like to _know_ that I should do that if I want to keep my settings. As a compromise you could append a warning or hint to the end of the merge and point out that the menu file _won't_ be kept. Thanks for your patience and I'd like to hear about the "changes" in the default file. ;-)
OK! I think I have this figured out, so tell me what you think! The box apps themselves should not be installing menu files. The only package that does that (or should be doing that) is commonbox-utils. With commonbox-utils I could cut the menu out of the main emerge and place it into a pkg_config() section. That way, the first time you emerge a commonbox/flux|black|openbox combination you would need to run 'ebuild /foo/bar/commonbox-utils-X.X.ebuild config' to generate your system default menu. After that, when you update *any* of the boxes or commonbox packages your menu file will not get overwritten and you don't have to worry about renaming it. Just ignore the 'ebuild config' step when upgrading commonbox-utils. This senario would likely benifit me as well, so if this sounds like an acceptable sollution I'd be happy to implement it this way. The only issue i can see with this is users not realizing they need to perform 'ebuild config' the first time they emerge a box app. The message will get displayed at the end of the commonbox-utils emerge but will quickly be replaced by compile lines from the wm that follows. The message *could* be displayed at the end of a box emerge, but then I would have to start version bumping the boxes just to correct textual notifications, and that's not a possibility. Let me know your thoughts!
ehm: I love you? =) Great solution, I think. If you need help, drop me a mail.
Just throwing in an update: I did some work on commonbox-utils tonight and reworked the menu placement. There are a few other things I'm trying to do also, but I'm haiving a few issues still. So I'm thinking of just rolling a new version with the menu changes for now, just to get that out there. This biggest issue with this new menu setup is that i still haven't found a good way to let the user know they need to run 'ebuild /var/bla/foo/c-u.ebuild config' the first time they emerge commonbox-utils. Like I mentioned, I can easily add a message in pkg_postinst(), but it's just going to zoom right off the screen. If I place some sort of notification into the boxes themselves it has to be generic enough so that they don't require updating every time commonbox-utils is changed. Currently I'm considering adding a line to the pkg_postinst() message that allready exists in the boxes that says something like: "If this is the first time you have installed Flux/Black/Openbox you MUST read /usr/share/commonbox/STARTUP.txt for instructions on creating a default menu." That way I can controll the contents of STARTUP.txt in commonbox-utils. Some sleep, and I should have a solution done by tomorrow.
New revisions of commonbox-utils, commonbox-styles, and commonbox-styles-extra have just been committed. -utils fixes issues with menu being overwritten. In all cases that I've been able to weed through so far, before any new files are created old ones will be backed up in their same location with a .bak extention. I'm now going through all the *box ebuilds to "make sure" and to do some other work. Enjoy! 10-4
