Re: .log directory
On Fri, 2010-01-29 at 18:17 +0100, Wolfram Kleff wrote: Request for Comments/Standards update suggestion: I would like to suggest a .log directory in the $HOME directory like the .cache directory. The .log directory would be a good place for all the log, history and recent files which litter the $HOME directory or fill up unnoticed in some config subdirectorys. Suggestions welcome ;-) Put them somewhere in $XDG_CACHE_HOME, because they are files that shouldn't hurt anything if removed. The cookie/socket files may break the operation of running programs on your system, so probably shouldn't go in CACHE_HOME, but not sure where they should go. Putting logs in CONFIG_HOME is bad, as logs aren't config. It would be nice though, if there was an XDG_STATE_HOME, similar to var, where you could put state information, such as the cookies/sockets, and information currently being stored in configuration, which is actually state (window size/position, etc...). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: OSD symbols
On Thu, 2009-12-10 at 21:07 +0100, Kenneth Wimer wrote: On Tuesday 08 December 2009 03:38:15 pm Rodney Dawes wrote: On Sun, 2009-12-06 at 16:43 +, Matthew Paul Thomas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jakub Steiner wrote on 02/12/09 22:55: ... What the important part here is that the color isn't defined in the icon itself, it's up to the widget theme to define in all sorts of different contexts like we have it for text. Eg. panel, menu, toolbar, when it's hovered over, disabled, that sort of thing. Maybe, but then someone would have to maintain a color naming specification (however simple) alongside the icon naming specification. I know of only one attempt to do something similar: CSS system colors, which was a failure. http://www.w3.org/TR/CSS2/ui.html#system-colors We'd need to identify what went wrong there and how not to repeat it. I don't think so. I think this should be handled as part of the symbolic addendum to the theme/naming specs. It should specify how to name, and how to design those icons so that we get the appropriate behavior with being able to alter the colors in the widget themes. This is important, because Qt or other widget sets may want to use the same icons in the same way, and we need to allow for the fact that they may not have the same states or color structure as GTK+. That said, I don't think we need to really care about things like warning and error colors. We just need to define that the paths that need to be drawn with the same colors as text, have the appropriate metadata tagging on them. I think that being able to add some colour is important. I suggest allowing as many colour values as needed and including a fall-back mechanism if any of those variables are not defined (to use just one color as suggested). Write the addendum, and we can discuss it better, since we'll have something tangible to alter. :) ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: OSD symbols
On Thu, 2009-12-10 at 21:01 +, Nuno Pinheiro wrote: this may be a very silly idea but i thought i should share, couldn't it make sense to simply make a font with all the symbols you need, as i told you guys KDE is probably going to implement this type of icons inside plasma specific theming, and use this as fall back... still a font would do the job pretty well, i think :D I can be very wrong :D I don't think a font is the right solution. If the answer is to not have things in the icon theme, then the better solution is to just draw the things in code, since nobody is ever going to change them anyway at that point. And if there is a need to, it's a simple change in code. Some things are already in the Unicode table, btw. Other things aren't, and so we wouldn't be able to reliably get the correct symbols from a font. One might install another font that has completely different symbols (could be letters in Klingon or something) in the same code page, and we'd end up having some weird stuff in the UI where icons should be. And icons at least allow us to have shinier icons when we don't want to have monochrome icons for stuff. I really don't like the whole monochrome icon thing. At least, I don't like it in the context of any current APIs and panels where they get used. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: OSD symbols
On Sun, 2009-12-06 at 16:43 +, Matthew Paul Thomas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jakub Steiner wrote on 02/12/09 22:55: ... What the important part here is that the color isn't defined in the icon itself, it's up to the widget theme to define in all sorts of different contexts like we have it for text. Eg. panel, menu, toolbar, when it's hovered over, disabled, that sort of thing. Maybe, but then someone would have to maintain a color naming specification (however simple) alongside the icon naming specification. I know of only one attempt to do something similar: CSS system colors, which was a failure. http://www.w3.org/TR/CSS2/ui.html#system-colors We'd need to identify what went wrong there and how not to repeat it. I don't think so. I think this should be handled as part of the symbolic addendum to the theme/naming specs. It should specify how to name, and how to design those icons so that we get the appropriate behavior with being able to alter the colors in the widget themes. This is important, because Qt or other widget sets may want to use the same icons in the same way, and we need to allow for the fact that they may not have the same states or color structure as GTK+. That said, I don't think we need to really care about things like warning and error colors. We just need to define that the paths that need to be drawn with the same colors as text, have the appropriate metadata tagging on them. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: OSD symbols
On Wed, 2 Dec 2009 17:52:13 +0100 Jakub Steiner jim...@gmail.com wrote: On Wed, Dec 2, 2009 at 5:11 PM, Kenneth Wimer kw...@sinecera.de wrote: Most important will be the foreground colors like normal, prelight, active, selected and insensitive. To keep things simple, we should treat the symbols as monochrome, ie. only one color is used and the symbol would be colorized in the very same way as text in the particular context. If a particular widget is prelit, fg[PRELIGHT] would be used (I guess that would have to be text[PRELIGHT] if it was a text entry widget. So in that regard injecting CSS or rendering it the way Patryk suggested would be equal. Just to clarify how the text/fg and base/bg colors work in GTK+... text and base are for text entry/list widgets. So symbolic icons appearing in GtkEntry or GtkTreeView would use text[] as the foreground color. Icons appearing on the panel or notifications would generally use fg[] as the color. If we're going to support doing this with formats other than SVG, then we will have to do the coloring in the same way that fonts work, and we will have to only use ONE color in the icons, as fonts do (though the color would really be irrelevant, as it's the shapes that matter, but complex shapes/gradients would not be usable). With SVG and named colors, we can specify more complex things. It might also be pertinent to allow the widget themes to specify gradients to apply to text as well. This would allow gradients to be used for the basic shapes, and take care of the concerns for having gradients of red for warning colors or such. How many other colors are needed? Warning/Failure, Success/Completion/New are two that come to mind. If we go for monochrome symbols, this would be a matter of coloring the widget's fg/bg. The symbol would get the very same treatment as the accompanying text. I think we should avoid recoloring particular falure/warning icons in the systray though. We might get away with stick an emblem on such symbols. http://dl.dropbox.com/u/24178/osd/notification.png Otherwise we would need to introduce some standard named colors in the widget themes and fall back to some default for those that aren't ready, which might not work for all of them. I think we only need the failure/error, warning, and normal colors. If you want complex icons, you shouldn't be drawing the symbolic ones anyway. You should be using a theme that doesn't have them. This is all an addendum to allow people who want to have these icons in places, to provide them in a theme, and use them. It's more of a treatment than a cure, for the problems with tray icons, and putting icons in text-centric widgets like GtkEntry. Do we need to consider animations (network manager comes to mind)? Good question. Going with the tiled single icon file like we have for process-working would probably be a cleaner approach than having a number suffix to multiple files. Going with whatever Network Manager expects now is probably the road of least resistance though? We should probably consider getting rid of animations in this area. The network manager animations are horribly confusing. And it also seems to lag a bit behind the actual network connection being alive. All in all though, the solution here is probably to fix these issues in NM, rather than trying to come up with nice animations for it. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Desktop usability issues: some comments from the country of bears, vodka and ISO8859-5
On Thu, 2009-09-03 at 11:17 +, Aceler wrote: John Tapsell johnflux at gmail.com wrote at Tue Sep 1 07:00:55 PDT 2009: Another issue - stealing focus. In X Window, every app that requests focus, gets it. I think KWin disables focus stealing by default. Either way, you can turn it on focus-stealing-prevention. Well, if you turn the focus stealing prevention in Kwin on, it will prevent focus stealing from all windows... including Open/Save dialogs for example. Also, it does not prevent window from raising — you will get an unfocused, but raised window. Very funny :) This feature, as I think, is useful only if you set focus follow mouse. Eh, preventing focus stealing is very very hard to get right, especially for very active users that open/close lots of windows quickly. The funny part though is that The Web is going through all the same bugs that have already been fixed in the desktop 10 times over, yet again. :( Try using some ajax-heavy web sites with sub-windows and dialogs and you'll see what I mean. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [desktop entry spec] new FullName key
On Thu, 2009-07-23 at 20:00 -0600, Aaron J. Seigo wrote: On Thursday 23 July 2009, Michael Pyne wrote: hearing someone from a i18n who has actually had a problem completing the translation because the current means available are insufficient. The i18n issues aren't in translating the text. It's that if you combine the two items on a single line, it may not appear to be correct in all languages. There's a lot you need to consider beyond is it translated? it hasn't come up, and we just recently had a full (and at time painful ;) review of i18n issues in the kde4 desktop shell which prompted a number of issues to be raised (and solved :). so either the status quo is just taken for granted and people are working around it to a satisfactory degree or it really is enough. Does KDE4 handle ordering of Name and GenericName correctly? IE, for RTL languages, does it do (GenericName) Name and such? i'll ask the i18n guys explicitly the next time i see them, though. (will be back home in a couple days, which will make that easier) Either way, I don't think adding FullName is the answer to the problems. Part of the problem (at least, for GNOME) is that the HIG tells developers to do things the broken way, which is generally not suitable for other desktops, or users. The way to fix broken UI isn't to change the spec to work with your broken UI, it's to fix the UI. Even in SUSE, the slab uses the 2-line with the reverse of what I think gnome-shell wants to do. And we had to patch a crapload of .desktop files so we could get the right strings, because so many of them are just broken. And translating the same string multiple times in one file just deal with UI issues seems like the totally incorrect way to solve whatever the actual problem is. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: freedesktop.org specification process
I generally disagree with the idea that in order to use the org.freedesktop namespace for DBus interfaces, you must first gain acceptance through having multiple desktops use your interface. This means that it will be much harder to gain acceptance (as I'm sure that lots of KDE developers are reluctant to use org.gnome services, and vice-versa, without there being acceptance). It also means that once that acceptance is gained, you either don't use the new namespace, or you are immediately required to break API compatibility. And I think encouraging the breaking of compatibility for this is probably one of the last things we want to do. This would be very painful for distributions and developers to deal with. Shouldn't we rather be encouraging people to use that namespace, and get their interfaces accepted as standards on FreeDesktop, rather than telling them to break API when/if they do get accepted here? On Thu, 2009-07-09 at 22:19 +0200, Cornelius Schumacher wrote: Following up on the discussion about freedesktop.org at GCDS and the additional input on the mailing list, I wrote down a specification for the process how to manage freedesktop.org specifications. It's based on the consensus we built at GCDS plus the input which came from Aaron and others before and after the meetings. To bootstrap the process I wrote it down as a freedesktop.org specification following the proposed process. You can find the text at http://gitorious.org/~cornelius/xdg-specs/xdg-specs-spec0/blobs/master/specifications/SpecificationProcess/specification.txt Please have a look and comment. The next step would be to work in your comments, and when this is done to merge it back to the main repository and get approval by the release teams. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: icon naming spec project on launchpad?
I've created a project [1] on Launchpad for this now. Please go ahead and file some requests there as separate bugs for each icon name. Both Ken [2] and myself should be notified of new bugs against the project. Thanks. [1] http://launchpad.net/icon-naming-spec [2] Ken Wimer is now a co-maintainer of the spec, for those unknowing. On Thu, 2009-06-25 at 19:02 +0200, Nicolò Chieffo wrote: There is the possibility to subscribe a new launchpad project about the icon naming spec, to better follow versions, bugs, feature requests, user questions. In my opinion we should go, because only using a mailing list can be more difficult to track things. Who agrees? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: basedir spec and plugins
On Tue, 2009-06-30 at 13:02 +0100, Simon McVittie wrote: ia64-linux-gnu (is the word size/endianness differentiation really necessary, or is there one endianness and word size that, in practice, everyone uses? If you really need to distinguish, talk to config-patc...@gnu.org, without which software that uses autotools probably won't compile for the other configurations anyway) ia64-hpux-32 (subtypes g++ and aCC) ia64-hpux-64 (subtypes g++ and aCC) Again, config.guess doesn't seem to distinguish: does nobody actually use one of these configurations? sparc-solaris-32 (subtypes g++ and CC) sparc-solaris-64 (subtypes g++ and CC) sparc-linux-32 sparc-linux-64 sparc-solarisN, sparc-linux-gnu, sparc64-linux-gnu. It might be worth asking the proposers of multiarch how their work relates to C++ compiler ABIs; in principle you could have sparc-solaris3-g++3 and sparc-solaris3-suncc, I suppose. Why not just lib32 and lib64? Do we really need some significant amount of complexity to deal with hosts/compilers/archs/etc... ? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: icon naming spec project on launchpad?
On Mon, 2009-06-29 at 23:09 +0200, Lennart Poettering wrote: On Sun, 28.06.09 18:10, Aaron J. Seigo (ase...@kde.org) wrote: The big problem is that noone else but Rodney is willing to maintain the spec. so, i should have asked this the first time, but i figured maybe an irc meet- up would be a better place for that. apparently we're at the point where we don't trust each other enough to feel that such a meeting would be valuable and result in something useful. so ... Lennart, can you let us know what the concrete issues you are facing with the icon spec are? please do so without assigning blame, pointing fingers or getting polemic. just describe what you wanted to see happen, and what actually happened instead. with concrete examples on the table, we can work through them. together. As always in free software someone needs to stand up and do the work. If there's someone who has the time, capabilities, interest and isn't crazy then he shouldn't have much trouble to get accepted as new maintainer of the spec. The spec is not the bible. It's just a list of generally agreed on names. There's no need to make all that fuss about it. Discussions like this one or the one whether a headset is more like headphones or the other way round are completely uninteresting and irrelevant. JFDI -- don't waste the time for talking. If it's just a list of things, it's not a spec, it's just a list of things. If you want to JFDI, then you're not looking for a spec, what you're looking for is to JFDI because you don't care. What you want to do is do it one way, be done with it, and expect that maybe someone will do it the same way when they have to do it. If it's going to be a spec which includes common names that multiple desktops use, then people from all sides need to be involved in the discussion. If it's one person, and the spec maintainer discussing it, and there is some confusion, and a deadlocked contention, it's obvious there needs to be input from some other point of view. But that is not what you want. Please also note that I am not a UI developer, only indirectly, where my stuff needs to covered in the UI. I am really not the one who you should be discussing all this. I just wanted three icons in the spec and then got pissed off by Rodney's way to handle that. Just read the archives. If you don't want to discuss it, then don't. Find someone who has the knowledge about the system and have them discuss it instead. You're pissed off because I didn't do exactly what you want. I had questions which were unanswered, and there was contention. I'm not going to stick icons in the spec if there is a locked contention like that. It doesn't make sense. If I make a patch to pulseaudio, and you disagree with it, and have some contention with me in the same way, you're going to tell me to shove off. I asked politely to get feedback from other angles, so that we can have the best solution in the spec, rather than the what one person did in one app/library, in the spec, which may not make sense for the organization of the spec, or other desktops. If requesting further feedback in order to make a more educated, and professional decision pisses you off, then have other maintainers isn't going to help. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: icon naming spec project on launchpad?
On Tue, 2009-06-30 at 03:58 +0200, Lennart Poettering wrote: On Mon, 29.06.09 21:40, Rodney Dawes (dobey.p...@gmail.com) wrote: Another reason to suggest using Launchpad Bugs to track their status. It provides meaningful status field information, priority, and threaded comments via the web and e-mail. It provides a nice place where only the relevant pieces can be viewed, unlike the current mailing list, which can get easily bogged down by unrelated threads, leaving the icon naming mails somewhere way down in the folder making them harder to find and track. Come on, really. Yes. Really. fdo has a bz that works perfectly fine. What's this thing with moving everything to LP? That's as if RH would suddenly move all the projects its developers work on to rhbz. It does have a bugzilla. And it does work. It's just less optimal than other solutions. And I don't want people complaining about the same problems in a different forum. If we're going to solve the problems, then they should be solved in a useful way. Bugzilla doesn't provide useful status tracking. It provides that a bug is either open or resolved. And we can't change those fields per-project. And the admin situation on bugzilla is even less optimal. Also, I find LP wildly confusing. If there are specific examples, please file bugs on Launchpad itself. I'm sure the developers and design team would be quite happy to have useful feedback so that the usability can be improved. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: basedir spec and plugins
On Fri, 2009-06-26 at 15:19 +0200, stefan.k...@nokia.com wrote: hi, the spec [1] only talks about XDG_DATA_DIRS/HOME - e.g. icons, docs, ... equiv of e.g. /usr/share XDG_CONFIG_DIRS/HOME - settings, equiv of /etc XDG_CACHE_DIRS/HOME - e.g. a plugin cache, equiv of /var/cache but there is nothing for plugins (equiv of /usr/lib). E.g. the user aquired the gstreamer mp3 decoder plugin from fluendo (which sits right now in ~/.gstreamer-0.10/plugins). If this would justify xdg where should t go instead? Would it make sense to add a XDG_LIB_HOME - $HOME/.local/lib gstreamer could then use $XDG_LIB_HOME/gstreamer-0.10/ This would be very nice indeed. However, there is a slight problem with the scope. What about 32-bit vs. 64-bit? And what about arch-independent plug-ins? I suspect they probably shouldn't all go in the same directory, especially for systems where you might dual-boot both 32 and 64 bit OSes. However, I do agree we need a solution, since plug-ins aren't really generic data or configuration information. Would we also want this for executables? XDG_BIN_HOME - $HOME/.local/bin Doesn't $PATH solve this already? I don't really see the point of adding another variable which duplicates what $PATH does. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: icon naming spec project on launchpad?
On Sun, 2009-06-28 at 14:31 -0600, Aaron J. Seigo wrote: On Sunday 28 June 2009, Lennart Poettering wrote: The big problem is that noone else but Rodney is willing to maintain the spec. if someone was found who would maintain it and had the appropriate experience to do so, would such a thing be accepted? I will accept help with maintaining the spec, yes. However, nobody really wants to actually help. A few people from Red Hat just seem to want to complain very loudly because they have some social problem with the maintainer, and refuse to cooperate in a manner that would work for everyone involved. i don't want to speak for others here, so i won't name names right now, but i can think of at least three people involved with art in F/OSS from different projects that i could see taking this on. if it's really an issue of find a new maintainer who can move it forward in a way that works for everyone involved, that's an easy one to solve. Frankly, you're not going to find anyone with the time or patience to deal with the annoyances involved. And nobody has come to me asking to help, either. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: icon naming spec project on launchpad?
On Fri, 2009-06-26 at 19:21 -0600, Aaron J. Seigo wrote: a couple of people have offered this POV now. this concerns me deeply, as KDE just recently adopted this spec. the only reason we went through all that work[1] was to gain the benefits of a shared spec. if the spec dies now, then our time and energy will have been wasted. It's a very malinformed point of view. I on the other hand, a few people demanding what they want, and being totally uncooperative, rather than being helpful and acting upon suggestions to further the discussion and come up with the best possible solution from the start, so that they may get their way. Red Hat developers seem to have this habit of developing features, and then demanding upstream pieces they depend on add support for their features, where upstream is already frozen, and has not been at all discussed with upstream. This has happened before with gnome-icon-theme, and is now occurring with the Icon Naming Spec. This is not the way to do development in the FOSS world. to me, this is not an acceptable outcome. and i can't imagine _anyone_ here thinking it is. so we probably all want the same thing, but there's something here blocking that from happening. classic group dynamic problem, right? :) having watched the past interactions around the icon naming specification, i have some inklings as to what that something might be made up of. (and it's more than one thing or one person.) there's evidently some unhappiness and disagreement around this, and as such i'd suggest that a mailing list is a poor way to deal with this. Mailing lists are generally a very poor way to deal with anything. Unfortunately, it's one of the best tools we have though. However, no technical solution is going to solve the social problems. here's my proposal to move this forward and not lose the baby with the bathwater: 1) let's get the spec itself into the git repository; i'm happy to do this myself even. then we have some place we can work on the end result in a collaborative fashion, and build workflow around this particular spec from there. if the workflow moves to launchpad or stays on fd.o's bugtracker and mailing lists, at least we'll have a place we can work together on the deliverable. We have a place where we can work together on the deliverable. Moving one xml file to a different source control system isn't going to solve the problems, which are social, not technical. Having commit wars in the VCS, instead of flame wars on the mailing list, isn't a solution. The proposal isn't to move that XML file to Launchpad, it is to move the discussion and status handling to the bug tracker there, as it provides a better work-flow for dealing with the needs of a specification, than anything we have on freedesktop.org at the moment. I don't know what you mean exactly by 'move the spec to git' either. I haven't had time to fully read your threads, and every time the Icon Naming spec is mentioned in a thread on XDG, it seems like one or more of the people from RH who like to complain about it, has to jump in and try to start a flame war, so now I'm having to deal with that, instead of having intellectual progressive discussion on more useful things. I don't have a problem moving the spec into a git repository if that will somehow actually solve some problems (which it won't really), so long as it's not a simply open git repository where anyone who maintains a spec can commit to other specs (because I'm pretty sure someone will), and I don't want to have to deal with the childish behavior of others who are unhappy and don't wish to attempt to get consensus in a properly useful way. 2) let's arrange for an irc meeting to discuss this. i'd suggest #freedesktop on irc.freenode.net, and one of the days between now and GCDS starting. i'm in a UTC-6 timezone, but am very flexible right now timewise and will commit to attending. if the others can RSVP to this email with days and times that work for them, we can nail it down. i'm happy to also serve as moderator for the meeting[2] if that would be deemed helpful, though i'd just as happily attend as a participant if someone else steps up to facilitate. I don't mind having an IRC meeting if something useful is going to come out of it. If it's just going to be some people venting and complaining, without any useful suggestions or acceptable behavior, I don't want to be a part of it. If some people don't want to respect the significant amount of time I've put into the specification, to get it into a state where it's used by KDE, GNOME, and XFCE, then I'm not going to give them the respect of listening to them moan for five minutes on IRC either. alternatively, if enough of the stakeholders will be at GCDS next week, a meeting could be schedule with those people for a F2F. (i unfortunately won't be there, as i'm moving house ... bad timing, i know.) I unfortunately won't be there, either. So that's
Re: icon naming spec project on launchpad?
On Thu, 2009-06-25 at 20:32 +0200, Julien Danjou wrote: At 1245949338 time_t, Nicolò Chieffo wrote: There is the possibility to subscribe a new launchpad project about the icon naming spec, to better follow versions, bugs, feature requests, user questions. In my opinion we should go, because only using a mailing list can be more difficult to track things. Who agrees? Why everyone tries to put things everywhere on the Internet, whereas there's a common place for all that stuff called Freedesktop? Bugzilla and MoinMoin don't provide useful work-flow for maintaining status and discussion of something like icon names. They are not particularly great for task oriented work-flows, while LaunchPad Bugs is designed more for a task based work-flow. And so there is a discussion as to whether we should use LP for managing this information for the Icon Naming Spec, or if people have better (or worse) ideas about how to do it. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: icon naming spec project on launchpad?
On Thu, 2009-06-25 at 17:20 -0400, Matthias Clasen wrote: On Thu, 2009-06-25 at 15:02 -0600, Aaron J. Seigo wrote: my only question is whether or not this is something that the various participants in working on the icon spec are in favour of? i assume/hope so, but as it hasn't been mentioned, i feel compelled to ask for clarity. I am certainly not in favour of moving fd.o project to launchpad, but I consider the icon naming spec more or less dead by now, so it may not make a big difference in this case... It's not moving the project to Launchpad, but simply using Launchpad to enhance the work-flow of handling status of individual icon name requests, and the discussions about them. It's pretty obvious that having the discussion on this mailing list isn't helpful. If you're just going to be rude and unhelpful, then don't bother replying, as your opinion is obviously only going to be poisonous. If you have *useful* commentary, then that's another thing, but stating your opinion that the spec is dead is not useful. You've made it abundantly clear that you don't give a damn anyway. Don't waste the time of those that are trying to help, with your hatred. It's not welcome. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: icon naming spec project on launchpad?
On Thu, 2009-06-25 at 15:02 -0600, Aaron J. Seigo wrote: On Thursday 25 June 2009, Rodney Dawes wrote: Bugzilla and MoinMoin don't provide useful work-flow for maintaining status and discussion of something like icon names. They are not particularly great for task oriented work-flows, while LaunchPad Bugs is designed more for a task based work-flow. And so there is a discussion as to whether we should use LP for managing this information for the Icon Naming Spec, or if people have better (or worse) ideas about how to do it. while it's a bit ironic to use a non-Free system, i completely empathize with the situation. It's actually scheduled to be open sourced at the end of July (which may turn out to be early August, if delayed slightly for testing). I don't know how willing any fd.o admins would be to deploy a Launchpad instance though. It's hard enough getting some admin tasks taken care of as it is. if you folks do move the discussion there, this should be clearly documented within the fd.o hosted resources, including the spec itself. that way we can keep the results of what you folks are doing in an easy-to-find place for everyone who needs to consult it (fd.o), allow people to easily find how to get involved and remove barriers to efficiency for you guys. It would be clearly documented with an announcement on this list, documentation on the wiki page, and an addition to the spec itself. my only question is whether or not this is something that the various participants in working on the icon spec are in favour of? i assume/hope so, but as it hasn't been mentioned, i feel compelled to ask for clarity. We don't really have a lot of 'participation' at the moment, as you may have witnessed on this list. Nicolo suggested doing the discussion and tracking of status with Bugzilla, and having used it and several other bug trackers for a long while now, I suggested possibly using Launchpad, as it would fit the needs and goals of the Icon Naming Spec much better. And he then started this thread as I asked him to, in order to gain input on this usage, or alternate ideas and suggestions. None of these are perfect options, but given the time I have to spend dealing with the mailing list, I certainly wouldn't have the time to write a complete new tool with a web app and all that, for a long while. I think using Launchpad to manage discussion and status is the shortest jump with the biggest gain at the moment. If there are better suggestions, I am glad to hear them, but the bug statuses, importances, and APIs which Launchpad has, makes it the best option in my experience, at the moment. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: about names for special folders
As I already stated elsewhere, I think folder-foo is better here, absent the usage of emblems on the normal folder icon, which would be more appropriate. Though, I think there are some oddities in the naming of the folders themselves, which we might want to avoid duplicating in the icon names for those folders, and push for changing the xdg folders spec. (I'll reply more on that later.) On Fri, 2009-06-12 at 13:04 +0200, Nicolò Chieffo wrote: There's the need to decide names for special folders icons (documents, music, pictures...) What do you think is better? - folder-foo - user-foo (note that currently we have user-trash, user-home, user-desktop) ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: desktop-bookmark-spec: disable recent files storage?
Hi, The Recent Files spec isn't XBEL. I don't know how implementable this is, but I think it would be better to store configuration in config somewhere. Perhaps this could be implemented via dconf (when it is available) or with an XSetting, so that it will work for both desktops. -- Rodney On Sun, 2009-06-07 at 17:03 +0200, Thomas Spura wrote: Hi list, is it possible to chance the xbel format a bit, to add a bool, if the recent files should be updated or not? This would solve the workaround to disable such collecting of recent files, which is not wanted by many users... See also bugs: http://bugzilla.gnome.org/show_bug.cgi?id=305325 https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/30942 http://bugzilla.gnome.org/show_bug.cgi?id=305325 Thomas ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: ThemePackageSpec (aka Metathemes)
Hi Torsten, I think the problem is that you're simply conflating the locations to mean that the icons and such *must* be part of some meta theme, when in fact, they do not have to be. Metacity, GTK+, and other themes currently stored in the themes path, can be completely independent, and a meta-theme could provide only a Metacity theme, and reference other GTK, QT, icon, or sound themes just as they do now. The only difference would be that the implementations would be looking in some additional place, than where they do now, to resolve those theme lookups. The number of files in those themes, and their location on disk isn't an issue that would require their location to be somewhere specifically away from where other theme content is kept. The bigger problem is that currently, icon themes and cursor themes, are stored in the exact same place on disk. The changes here would fix that, and make it simpler for artists to package entire collections of themes as a desktop theme, which they can't do now, because all of the files are in independent locations on disk. With the proposed change, the GNOME icon theme for example would simply switch from: /usr/share/icons/gnome/ to: /usr/share/themes/gnome/icons/ It's quite a simple change, with lots of benefits. I've even advocated making the change several years ago, but alas. -- Rodney On Sat, 2009-06-06 at 12:53 +0200, Torsten Rahn wrote: I think there is a known problem with your approach. There is a good reason that icons and sounds were always kept in distinct directories: Iconsets and sounds have the exceptional property of * involving many files * consume a lot of space on the device * are time-consuming to produce That's why a specific icon theme is often (re)used by several meta themes. And of course you don't want to copy icon themes into every single meta theme folder that they get reused by and of course you don't want to work with symbolic links either. This and the fact that icon themes are able to inherit other iconthemes makes packaging the icons on a per single content folder base quite problematic. So this needs to get somehow dealt with. Regards, Torsten Am Samstag 06 Juni 2009 11:04:40 schrieb Stephan Arts: On Thu, Jun 4, 2009 at 3:59 PM, Rodney Dawes dobey.p...@gmail.com wrote: On Wed, 2009-06-03 at 09:19 +0200, Stephan Arts wrote: On Tue, Jun 2, 2009 at 7:47 PM, Rodney Dawes dobey.p...@gmail.com wrote: The biggest issues I see, are icon themes, cursor themes, and sound themes. These are currently installed in separate paths from other theme bits, and cursors and icons are both under icons, which is yet another issue. I think the best way forward is to probably get the specs for those themes updated to install under themes/$NAME/$type first, with the current paths listed for backward compat, but as deprecated, before getting some spec together that either moves them all to some other place independently, or requires lots of code to magically install/uninstall them to/from the correct places listed in the respective specifications. Agreed. So, for the locations we would have something like this: $XDG_DATA_DIR/themes/$NAME/$type where type can be anything, but has reserved names for: icons cursors wallpapers sounds which are dedicated to sound-themes, wallpapers, cursors and icons. Other dirs could be: gtk+2.0 metacity xfwm4 What do you think? I think we need to get the specs changed (I don't think there is a proper spec for X cursors though). I don't know what KDE does for kwin, KDE, and QT themes, but we'd need to get them changed to be similar as well. AFAIK, there is no proper spec for X-cursors, and the X cursor implementation seems to be considered buggy. And KDE... it's a bit messy: /usr/share/kde4/apps/color-schemes/ ~/.kde/share/apps/desktoptheme/ Regards, Stephan ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Voting mechnism is needed for xdg discussion.
Popularity contests are not the way to solve design issues. Also, we already have a forum for voting on these issues. It's called mailing list discussion. Having a straight yes/no vote on the issues doesn't dissect the issues that may in fact cause other issues, which is why they aren't getting consensus, or are dropped. On Fri, 2009-06-05 at 21:02 +0800, PCMan wrote: Hi all, I'm lead developer of LXDE, a lightweight desktop environment following xdg standards. As everyone on this mailing list knows, current desktop environments have many long-standing issues without consensus. All too often someone might have some proposals on the mailing list, and gets replies from several people, and then, the discussion just disappears. The issues are still there. Otherwise, there might be someone says If there is no objection, I'll add to the spec. Later, maybe nobody noticed that issue, and the spec was changed silently. Besides, if the original author of that spec doesn't agree the change, no matter how many people want it, the spec won't be changed. This is not a really good way to achieve the goal of xdg. A more democratic and efficient way is hence needed. I propose setting up a voting mechanism for some unresolved issues. A forum hosted on freedesktop.org or some other places is acceptable. For unresolved but critical issues, like naming of some icons in the icon theme spec, we can wait a period of time (maybe one week) and let the users nominate possible options. Then, a vote can be held, and the users on this mailing list can vote on those issues. If the people joining the vote is too few, the result can be invalid. Otherwise some unresolved issues can be settled. Please consider this. Voting can definitely improve the efficiency of decision making. Besides, the result of the vote can be acceptable by most of the developers. We can know what most developers really want. Since the specs were formed in a democratic way, most implementers will happily follow them and the controversies can be minimized. If nobody is going to do this, we're willing to set up a forum for it. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: ThemePackageSpec (aka Metathemes)
On Wed, 2009-06-03 at 09:19 +0200, Stephan Arts wrote: On Tue, Jun 2, 2009 at 7:47 PM, Rodney Dawes dobey.p...@gmail.com wrote: The biggest issues I see, are icon themes, cursor themes, and sound themes. These are currently installed in separate paths from other theme bits, and cursors and icons are both under icons, which is yet another issue. I think the best way forward is to probably get the specs for those themes updated to install under themes/$NAME/$type first, with the current paths listed for backward compat, but as deprecated, before getting some spec together that either moves them all to some other place independently, or requires lots of code to magically install/uninstall them to/from the correct places listed in the respective specifications. Agreed. So, for the locations we would have something like this: $XDG_DATA_DIR/themes/$NAME/$type where type can be anything, but has reserved names for: icons cursors wallpapers sounds which are dedicated to sound-themes, wallpapers, cursors and icons. Other dirs could be: gtk+2.0 metacity xfwm4 What do you think? I think we need to get the specs changed (I don't think there is a proper spec for X cursors though). I don't know what KDE does for kwin, KDE, and QT themes, but we'd need to get them changed to be similar as well. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG Icon Spec: requesting new icons for headsets, speakers, headphones
On Thu, 2009-05-14 at 11:25 +0300, Marius Vollmer wrote: True, but what might work is to have a second Extra Icons spec that works together with the base icon spec. This Extra Icon spec would, by design, have the same goals as the base spec, but would be maintained in a more 'reasonable' way. I.e., it wouldn't be a ever-growing set of ill-conceived icons, but it would also not be a fortress of resistance. This already exists. It was in fact, the original goal and intent of the specification. But it's quite obvious nobody actually pays any attention to it, or even gives a damn. There is an addendum specification for device icons at http://people.freedesktop.org/~dobey/device-names.txt and has been for a long while now. And the base spec clearly identifies how to name these device icons anyway, for specific types of devices, with only the base types being in the base spec, so everything falls back to those base types. There's always been the desire to have such addenda for other categories as well, However, no one else has actually shown any interest whatsoever in helping create them. And if I'm going to have to do all the work, then everyone else is going to have to have some ounce of patience and wait, because I can't do all 357000 things that I need to do, simultaneously and instantaneously. If you can't wait, then get off your asses and do something to help. You don't get to bitch and moan when you've done absolutely nothing to help further the goals of the specifications. And making demands that your precious two icons that you think your precious app absolutely MUST have, be in the spec, is not furthering the goals of the specification. I have stated it several times before, and I will say it again. The base specification (that bit of docbook in freedesktop.org cvs) is a base specification, designed to be the minimal list of icons that everything else can fall back to. It is not going to have every little icon that ever random developer thinks needs to be in the spec for their app to have that icon. It doesn't make sense. We used to have a list of icons that every app used (in GNOME anyway) [1], and it was a complete and utter travesty. The problem is not the specification, or its maintainer. The problem is that developers don't give a damn about icons. They think they need an icon, and so they must have it. And the artists just want to draw icons, and not deal with all the political crap, for the most part. And there's no real communication between them. There's no real UI design happening. Apps just get thrown together as an compendium of features that the developers think the users actually need to use or even remotely care about, rather than considering what users really need, or how to present it to them without being overwhelming, and blithely throwing a bunch of icons at them, to make their interface seem pretty and give a false sense of usability. This is especially evident in KDE, where the main Oxygen artist has stated very bluntly to me that he does not wish to involve himself in suggesting to developers possibly better ways to present UI to the user, but rather simply wants to draw the icons. And the developers of course, do not ever ask for such feedback from said artist. Where in GNOME, as a result of that horrible travesty [1], the icon theme maintainers have sort of taken it upon ourselves to ask questions about an icon's usage when one is asked to be created, and to give feedback about potentially better ways to build the UI, and perhaps avoid the icon all together, when necessary, so that we can actually have proper metaphors for all the icons and their usage, and help improve the desktop's usability at the same time. In short, no I have no problems adding icons to the spec. But I won't go adding every single icon, that every single developer asks for, with the blind hope that it makes sense in the spec. It's funny how nobody really wanted to get involved in the discussion for suggested icon additions to the spec, but everyone comes out of the woodwork when it's time to insult the maintainer. Don't you people have anything better to do? Fix some bugs perhaps? The goals of the spec have not changed. They are the same now, as they were four years ago, when I wrote the first revisions. If you disagreed with those goals, you should have made such known four years ago when I initially wrote and proposed the spec, when nobody had yet adopted it really. Now is not the time to argue over the goals of the spec. They have been set, adopted, and in use now for a few years. I spent a lot of time in that first year as well, in order to make the spec more easily adaptable by KDE, I made significant changes to the spec. It was said to me four years ago when writing the spec, that I seemed to be the only person to actually give a damn about the problem, and it seems that is still the case, unfortunate as it is. We really need to have feedback from multiple app developers, and artists
Re: XDG Icon Spec: requesting new icons for headsets, speakers, headphones
On Thu, 2009-05-14 at 11:55 -0700, Brian J. Tarricone wrote: and has been for a long while now. And the base spec clearly identifies how to name these device icons anyway, for specific types of devices, with only the base types being in the base spec, so everything falls back to those base types. Except clearly the list is incomplete and there are other device types (like speakers and headsets) that you hadn't thought of. This list doesn't help Lennart's case. That's fine. But when I make suggestions and the original proposer tells me no that doesn't make sense and no one else is involved in that discussion, there's obviously an impasse. Telling me that hierarchy doesn't matter, when the entire point of the Icon Naming spec is the hierarchy, is also not helpful to the cause of getting the names added. All it tells me is that someone wants stuff added, but doesn't want to be cooperative and figure out the best solution for EVERYONE. There's always been the desire to have such addenda for other categories as well, However, no one else has actually shown any interest whatsoever in helping create them. And if I'm going to have to do all the work, then everyone else is going to have to have some ounce of patience and wait, because I can't do all 357000 things that I need to do, simultaneously and instantaneously. Except you *aren't* doing all the work. You aren't doing *any* work beyond emailing this list to deny requests and come up with reasons why XYZ icon name is a bad idea. No. I never actually denied these icons, or specifically stated they were a bad idea. I asked questions about how they would be used, and what they are, and how to organize them, and to get other people to comment. No one else commented. And I was told the organization isn't important. In fact, I very recently added an icon to the spec. But I guess it doesn't matter because it wasn't /your/ icon, right? If you can't wait, then get off your asses and do something to help. That's exactly what people are trying to do here, but it's unclear as to how to proceed because of your involvement. I have made it very clear several times how to proceed. We need more people discussing these things. This thread was dead until everyone started to flame me. Why weren't you involved in the original discussion? Where are your comments about the suggestions I made, and the questions I asked? From this end, all I see is people looking for some excuse to bitch and argue. And neither of those is particularly productive. Either you don't care about the icons in the first place, or you involve yourself in the discussion and try to help get a meaningful resolution. Waiting until the flames start broiling isn't helpful. You don't get to bitch and moan when you've done absolutely nothing to help further the goals of the specifications. And making demands that your precious two icons that you think your precious app absolutely MUST have, be in the spec, is not furthering the goals of the specification. Guess what? The goals of the specification (whatever the hell that means; inanimate documents don't have goals) are irrelevant. The needs of the community and of the people who will use the specification are paramount. If it's irrelevant, then obviously the entire point of freedesktop.org is irrelevant. Developers aren't the only ones with needs. In short, no I have no problems adding icons to the spec. Then add the icons that people think are necessary rather than stonewalling at just about every single request. I will when it makes sense to do so. Demanding I do so is not going to get it done. I've said that before, and it remains. We need proper consensus, not demands. But I won't go adding every single icon, that every single developer asks for, with the blind hope that it makes sense in the spec. You're not adding every single icon. From my on-and-off observations over the past couple years, you add very few icons. It's too conservative, at least according to sentiment expressed here. You can either respond to what the community needs, or you can blindly push forward with your own agenda that no one really cares about and doesn't actually help developers and artists *in the real world*. Too bad you've taken the latter choice. There have been very few proposals for new icons. Don't blame me for lack of participation by others. It's funny how nobody really wanted to get involved in the discussion for suggested icon additions to the spec, but everyone comes out of the woodwork when it's time to insult the maintainer. No, everyone comes out of the woodwork when they realise that there's a systematic problem. Doesn't look that way to me. Just looks like everyone wants to complain about something they're not involved in at all in the first place. Do I care about sound/speaker/headset-specific icons? No, I don't. I don't work in the desktop
Re: XDG Icon Spec: requesting new icons for headsets, speakers, headphones
On Thu, 2009-05-14 at 16:08 -0700, Brian J. Tarricone wrote: Rodney Dawes wrote: On Thu, 2009-05-14 at 11:55 -0700, Brian J. Tarricone wrote: No. I never actually denied these icons, or specifically stated they were a bad idea. I asked questions about how they would be used, and what they are, and how to organize them, and to get other people to comment. No one else commented. And I was told the organization isn't important. In fact, I very recently added an icon to the spec. But I guess it doesn't matter because it wasn't /your/ icon, right? If no one else comments, it may just mean they don't know. It may mean they don't care. In the absence of anything else, you have a fairly prominent developer with a problem and a way to solve it. So what do you do? You can either accept what the developer wants, or you can just put up a seemingly-impenetrable wall of I don't understand the use case so I'm not going to proceed. You can't always get consensus and advice from other parties. Then again, if the spec is a list of well known names used in lots of places, it probably doesn't make sense to stick icon names in there that only one app and one developer uses. It's not that I'm not going to proceed, but if I can't get a reasonable discussion out of the person proposing, and nobody else is joining in to provide that reasonable discussion, then there isn't too much I can do. And when I notice that something is a mistake from the original write-up of the spec, and I suggest changing it, and aligning the newly recommended names along with that change, and all I get you can't make that change, it should be done this way then there isn't much I can do with that either. If I go ahead and make those changes, and the person proposing the new icons continues using the names they asked for, rather than the ones added to the spec, then what's the point? Sometimes, there just needs to be a couple more people providing input, to avoid those situations. (For the record, I've never asked for an icon to be added to the spec. Though I suppose you could be using your in the generic sense there.) If you can't wait, then get off your asses and do something to help. That's exactly what people are trying to do here, but it's unclear as to how to proceed because of your involvement. I have made it very clear several times how to proceed. We need more people discussing these things. This thread was dead until everyone started to flame me. Why weren't you involved in the original discussion? I told you: I don't know anything about sound systems. But since you asked, here's my uninformed opinion on the specific case: And that's fine. I don't know a whole lot about them either. That's why I ask the questions I ask. I want to increase my knowledge, so that I can perhaps take in the request, and make other recommendations, and so that others who decide to join the conversation, will have more information about the request and what it entails. I don't see why some people think this is a problem. But alas. I think 'audio-card', 'audio-speakers', and 'audio-headphones' make sense based on Lennart's definition. As for -headset and -handsfree, I'm not sure. They both serve a similar function (vocal audio input plus audio output), but, physically, they're very different devices. Maybe one should be a sub-type of the other, e.g. audio-handsfree for the separate device, and audio-handsfree-headset for the wearable kind? I dunno. They don't seem to 'degrade' reasonably to me; if there's no -handsfree-headset variant in the theme, the user might be a big confused to see an icon depicting a non-wearable handsfree device. But the reverse is also true with -headset as the parent and -headset-handsfree (which language-wise doesn't even make sense) as the specialisation. Maybe a hybrid approach? -handsfree as a generic type, and then -handsfree-headset for headsets and -handsfree-something as the non-wearable device? Of course then that means three icons instead of two, and the required one (-handsfree) doesn't really have a good definition. I don't even know how one would draw an icon of a 'handsfree' device that you don't wear. Technically speaking, my computers are 'handsfree' devices, as I don't need to use my hands to have a skype call with someone. And I think we at least did reach consensus that 'handsfree' doesn't make much sense for an icon. I dunno; kinda at a loss. Personally I'd probably just give up and add both -headset and -handsfree. Bluetooth actually has separate device classes for headset and handsfree device (and I believe some devices may report that they support both) so it would be beneficial to require different visual representations. It would look weird to have two icons the same for two different device types (even if the devices are similar). Ok, so I guess I do have an opinion after all
Re: XDG Icon Spec: requesting new icons for headsets, speakers, headphones
On Tue, 2009-05-12 at 23:19 +0200, Lennart Poettering wrote: On Sat, 02.05.09 16:14, Lennart Poettering (mz...@0pointer.de) wrote: On Tue, 21.04.09 01:41, Lennart Poettering (mz...@0pointer.de) wrote: I am still convinced that having these four (or five) icon names for all things audio woul be sufficient: audio-card --- the generic icon for everything audio that has no or an unknown form factor audio-headset --- Mono/Duplex audio devices that are attached to one's head audio-headphones--- Stereo/Playback only audio devices that are attached to one's head audio-speakers --- Standalone speakers. Black boxes audio-handsfree --- handsfree devices, no priority That would only require the addition of three (or four) new icons. That's it. No renaming. No discussions about hierarchies. Rodney, please, can we agree on these icons now? I really would like input from someone other than you. Someone else that would be using the same icons in their software. People that use the icons that I recommended renaming. But apparently the community just doesn't care. Developers will either use what's available, demand something else be added, or just use whatever they want anyway. The latter 2 seem to be the common case, unfortunately. I decided to just go ahead and make use of these icons names now. I have been trying to get this into the spec now for two months, unsuccessfully. Disappointed, Lennart Just as I am as well. I've no problem adding and renaming icons in the spec, but we really need community input, and not one developer demanding a few icons without any real consensus. Why does no one want to be involved, yet everyone wants to complain? It's ridiculous. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG Icon Spec: requesting new icons for headsets, speakers, headphones
On Fri, 2009-04-10 at 03:33 +0200, Lennart Poettering wrote: On Wed, 18.03.09 21:56, Lennart Poettering (mz...@0pointer.de) wrote: May I suggest the following names? audio-card (as it exists right now, intended for the generic idea of 'audio') I really want to change this, but I'm not sure what to. Having foo-card doesn't really make sense for any of the devices. I don't know what I was thinking when I came up with the -card names. I think we might want to get rid of the audio- and video- prefixes for devices as well. I'm not sure what would be best to call some of the devices, without the audio- prefix, but there are headsets that handle both audio and video, for example. But speakers and headphones are audio only. A television/monitor with speakers is still primarily a display, not speakers. I think you probably would rather display the device icon for a webcam, for adjusting the volume of the microphone on that device, rather than a microphone icon. audio-headset audio-speakers audio-headphones audio-handsfree (no priority, feel free to ignore this part) I think headphones is probably a sub-class of speakers. They are just a special casing for small speakers. With what I suggested above, the icons would then be: headset microphone speaker (replacing audio-card) speaker-headphones display (replacing video-display) And a couple of device-specific names would be: headset-samsung-wep200 display-samsung-syncmaster-2343bwx (as opposed to video-display-...) What do people think about this? We'd probably want to also rename the status icons from audio-volume-... to speaker-volume-... Comments, complaints? Rodney, Ping? Sorry for the slow reply. Have been extremely busy with other things... ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG, xdg-open, and view vs. edit
On Mon, 2009-03-30 at 19:25 +0200, Patryk Zawadzki wrote: On Mon, Mar 30, 2009 at 4:34 PM, Pat Suwalski p...@suwalski.net wrote: Daniel Bo wrote: That said, I wonder why the choice was to set a default application for opening when most file types have view and edit modes. Why are there not xdg-view and xdg-edit (or --edit and --view switches on xdg-open)? My opinion is that it's because most programs don't differentiate between editing and viewing. You start the program with a file parameter and then you can do anything. In that respect, you're Opening the file just like from the File-Open menu. While this is true you might need two separate applications for editing and viewing files. Also at times you might want to programmatically determine if there is a viewer/editor available (for example it does not make sense for an edit button to open a PDF file in Evince). Unless it's a PDF form, which you are editing... ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon Theme spec and multiple index.theme
On Mon, 2009-03-16 at 18:36 +0100, Sanel Zukan wrote: Does this mean that when $HOME/.icons/foo-theme/index.theme was read, all other directory entries from /usr/share/pixmaps/foo-theme/index.theme are ignored, except 48x48/apps? Yes. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG Icon Spec: requesting new icons for headsets, speakers, headphones
On Wed, 2009-03-11 at 11:08 +, Bastien Nocera wrote: they both require a jack-plug, bluetooth- or irda interface to send audio from a machine to your ear. Given that thinking, a scanner, a camera and a webcam are the same thing as well :) I certainly use my DSLR to scan receipts for expense reports, and sketches I've made to draw icons or such. :) ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: sending apps to the right place in the (new) submenu
This is handled through categories. Of course Rhythmbox doesn't play multiple types of media yet afaik. It only does music. :) If the categories in the .desktop file for the app, and the .menu file match up, then the app shows up in that menu, unless the implementation is doing something wrong/weird/different. If you read the menu spec, you will see how the categories stuff works. -- dobey On Wed, 2009-01-14 at 16:23 +0100, schoappied wrote: Hi, I know it is possible to customize the menu in Gnome. But I am wondering if it is also possible to send applications to a specific place in the menu? For example, I want to add an entry in the menu called 'multimedia players'. Is it possible to manage it so that apps like Rhythmbox, Listen etc. are placed in the new entry when they are installed? I know I can place them in the entry after installing the app. But my question is about doing this automatically. I hope I made this clear enough for you. Thanks in advance, \r ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: sending apps to the right place in the (new) submenu
On Wed, 2009-01-14 at 20:21 +0100, schoappied wrote: Rodney Dawes wrote: This is handled through categories. Of course Rhythmbox doesn't play multiple types of media yet afaik. It only does music. :) If the categories in the .desktop file for the app, and the .menu file match up, then the app shows up in that menu, unless the implementation is doing something wrong/weird/different. If you read the menu spec, you will see how the categories stuff works. -- Ok, so 'each' source of an application contains a file *.desktop. If I want to make sure it will be placed in the new (sub)menu, I have to edit it. I'm thinking of a redesign of menus cause I want to build a custom multimedia distro. Now all the audio and video apps in Gnome are displayed in 'audio/video'. That means in a average Linux multimedia distro that you got about 15 different apps in that menu (Linux - one task one app...) . This confuses especially newbies, so it would be much better to have something like: Audioproduction Tools Qjackctl meterbridge Recording Ardour Audacity MIDI Rosegarden Qtractor And this is what the secondary categories in the spec are for. SUSE for example splits things into sub-menus like this, using the secondary categories. You might want to look at any patches they have. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
On Sat, 2009-01-10 at 22:09 +0100, Dieter Plaetinck wrote:
Hi all,
at http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
it is explained that $XDG_DATA_{HOME,DIRS} is for (user specific) data
files and $XDG_CONFIG_{HOME,DIRS} for (user specific) configuration
files.
However, it is not exactly explained what each mean.
Specifically, afaik everything that goes into $XDG_CONFIG_HOME should be
controlled by the user himself, eg any update of files in this directory
is the result of:
- the user updating the file himself manually.
- the file being updated because the user changed one or more settings
in a GUI panel.
Eg: Isn't it wrong for software to update files in $XDG_CONFIG_HOME (and
by extension $XDG_CONFIG_DIRS) around the users back?
I've seen many programs who store things like last window position,
last 10 opened items etc in $XDG_CONFIG_HOME. I don't think this is
what $XDG_CONFIG_HOME is for (I think this belongs in the user data
category), but then again, I couldn't find this being defined in the spec.
Do you agree with this point of view?
If so, I would be happy to contribute an updated version of the spec
based on the above wordings.
If I resize my app's window to be more suitable for my uses, where
should that configuration be saved then? It is configuration data,
though all configuration data may not necessarily be what you expect
it to be.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: No category for blogging clients
On Mon, 2009-01-05 at 07:03 -0500, Fred Drake wrote: On Mon, Jan 5, 2009 at 4:13 AM, Matthew Smith indig...@blogistan.co.uk wrote: The problem is that none of the registered categories actually cover blogging clients, as it's not a web browser nor a web development application (let alone any of the other network subcategories). Can I suggest registering a weblog client category? Perhaps something more like a specialized Web-application client subcategory would be a good idea? I don't expect many people will install several blog authoring clients, but specialized front ends for a variety of online apps are likely to be around for a while. I don't see why we should duplicate the menu under Internet for apps which are specifically web clients, but would otherwise be normal apps. Most apps should peruse network connectivity for various things anyway. I'd expect Google Calendar to show up in the same place as Random Local Calendar App for example. -- Rodney ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: minimal list of must have icons
The Icon Naming Specification itself only provides the minimal list of names. I've changed the text you referenced, to clarify this, in CVS. There will be addendums to provide lists of names for extra icons, such as devices[1] and MIME types. The names in the spec itself are intended to be the base set, and thus what everything falls back to, and so should be the priority when creating a new theme. -- Rodney [1] http://people.freedesktop.org/~dobey/device-names.txt On Sat, 2009-01-03 at 17:30 +0300, Vasiliy Faronov wrote: Hello. The Icon Theme Specification 0.8.90, according to the Overview section, aims to provid[e] a minimal list of must have icons, and a larger list with many more examples to help with the creation of extended icons for third party applications, devices, and new MIME types.[1] However, as far as I can tell, the specification only contains one list of icons along with their names[2]. No separation by priority. Is this the must have list, or the larger one? In general, are there any recommendations on the priority of icons (i.e. which ones are more essential)? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon naming spec: generic binary MIME type icon?
On Sun, 2008-12-07 at 13:52 +0200, Ville Skyttä wrote: On Sunday 07 December 2008, Rodney Dawes wrote: On Sat, 2008-12-06 at 01:05 +0100, Jakob Petsovits wrote: Yes, of course. I'm aware that gnome-icon-theme has little relevance to spec issues, and did not intend to imply any connection, just that it's not currently possible to use an application-octet-stream icon while assuming that it will actually be present. Well, the point of the spec is to have generic fallbacks, and so you can query for things which aren't necessarily going to be in an icon theme. We now also have generic icon names specifiable in the shared-mime-info data, and in the Shared MIME spec. Yes, this is exactly what prompted me to start this thread: shared-mime-info apparently has chosen to use the text-x-generic generic icon at least for some things for which there's no better standard generic icon available in the icon naming spec, even if the files of the MIME type are binary files, not text? Well, binary is not a particularly useful classification. Neither is application really. For certain file types it definitely doesn't make sense to be using text-x-generic. And none of the icons in the current spec may make sense. In the cases where they don't, we really need an appropriate classification for those types, so that we can create a generic icon for that classification, and not generic random data icons, which would be entirely useless to a user. For example, the generic icon for application/x-pkcs12 in shared-mime-info is text-x-generic which makes no sense to me. I'm not sure that this one doesn't make sense. pkcs certificates are just a long string of characters, with line breaks, no? Maybe these (now that I look into the XML, there actually is just a few of them) are just bugs in shared-mime-info and non-text files for which there's no better generic icon name available in the icon naming spec's standard mime type icons list should not have any generic-icon specified whatsoever? Or alternatively, an icon for generic binary files could be added in the standard mime type icons list so that could be used instead of leaving out generic-icon altogether in shared-mime-info (or using something (IMO) clearly wrong such as text-x-generic for them in it, or using something like application-octet-stream in it which is not in the standard mime type icon list and thus cannot be trusted to be available)? Yes, if there are types that existing generic icons in the spec don't cover, we need to classify those types appropriately and come up with appropriate names for them. Just binary isn't very useful (technically speaking, everything in the computer is binary). :) -- Rodney ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon naming spec: generic binary MIME type icon?
On Sat, 2008-12-06 at 01:05 +0100, Jakob Petsovits wrote: Yes, of course. I'm aware that gnome-icon-theme has little relevance to spec issues, and did not intend to imply any connection, just that it's not currently possible to use an application-octet-stream icon while assuming that it will actually be present. Well, the point of the spec is to have generic fallbacks, and so you can query for things which aren't necessarily going to be in an icon theme. We now also have generic icon names specifiable in the shared-mime-info data, and in the Shared MIME spec. On the other hand (and no, I don't enjoy being a pain in the neck), your reply does not say anything about whether such an icon (be it application-octet- stream or a more generic one) could go into the spec or not, which was the original question. Perhaps there just needs to be some more clarification in the spec about how the fallback works for MIME types? I thought it was clear in the spec, but looking again, it looks like there could be some more clarification there. -- Rodney ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon naming spec: generic binary MIME type icon?
On Thu, 2008-11-27 at 20:39 +0200, Ville Skyttä wrote: Hi, I think the icon naming spec is lacking a generic binary MIME type icon. For example, recent shared-mime-info has set text-x-generic for a lot of file types that have nothing to do with text, I suppose because there's no better alternative available. And I guess this will result in an icon for text files being shown for quite a few binary files in some contexts, and being confused (Hey, the icon shows this is a text file, I have several text editors installed, why doesn't it open when I click it? or Why does this text file show only gibberish when I open it in a text editor?). How about adding let's say binary-x-generic: The icon used for generic binary file types. What do you define as a generic binary file type? JPEG and PNG are binary file types. As Jakob already replied, the standard mime type for unknown binary files is application/octet-stream so you should use the application-octet-stream icon. If there really is some need for a more specific generic icon, then we can discuss that, but afaict, your solution is to use application-octet-stream. -- Rodney ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon naming spec: generic binary MIME type icon?
On Thu, 2008-12-04 at 10:26 +0100, Jakob Petsovits wrote: On Tuesday 02 December 2008, Rodney Dawes wrote: It is maintained. And I am very easily contacted. You might consider to reply to the original post in this thread. I believe the lack of feedback about past proposals contributes a major portion to the (perceived?) maintenance and communication problems. I have replied to that mail now. Your reply would have been sufficient if you hadn't made derogatory remarks about the maintainership of the spec, and gnome-icon-theme. The fact is that gnome-icon-theme has nothing to do with the spec, other than that it uses it. There are plenty of icons in it, which aren't in the spec, and shouldn't be. I do however maintain it, as well as Tango, along with the artists working on them. I can't exactly have the artists experiment with metaphors and icon names in themes which I don't control, very easily, now can I? A short answer to each of the incoming spec proposals might do wonders, e.g.: * I think that's a good idea, and I'll add it to the spec as soon as I find time. * I don't think that's a good idea, because (...) [suggestion is reworked, reposted, and then receives another judgement] * I have a fundamental issue with this: (...). Such an icon will never go in. * I can't say much at the moment (requires more research), but I'll look into it as soon as I find time. * I'll never find time for *this* crap, f*ck off and bl**dy leave me alone. You might optionally go into more details, but this kind of feedback is the least that a contributor can expect from the spec maintainer. Omitting even this minimal feedback is basically the same as the last option, which is why the spec appears to be unmaintained even if that's not the whole truth. I do tend to reply naming spec proposals. I don't really reply to silly quarrelsome mails though. Replying to my asking for more information, arguing that I'm being uncooperative is just dumb, and untrue. If there was a mail that had several proposals, and thus required more of a reply, I may have not had time when I got the mail, and being overwhelmed with other priorities, it may have slipped by completely. If that is the case though, I can always be pinged on IRC or in e-mail to reply. When initially working on the spec, I made several changes to make the spec fit better with KDE. So just calling me uncooperative and whatever other useless names people want to come up with and throw out in e-mails whenever spec mail comes up on the list, is completely false, and a waste of everyone's time. Please keep the content in relation to the mail being replied to in the future, and leave out whatever personal feelings you have about the maintainer because you disagree with one little thing here or there. Thanks, Rodney ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon naming spec: generic binary MIME type icon?
It is maintained. And I am very easily contacted. On Tue, 2008-12-02 at 21:51 +0800, PCMan wrote: Second that! Forking is needed if the original spec is no more maintained and the original maintainer cannot be contacted. On Tue, Dec 2, 2008 at 9:07 PM, Richard Hughes [EMAIL PROTECTED] wrote: On Mon, 2008-12-01 at 10:59 -0500, Matthias Clasen wrote: I propose to use the staging area as a way to work around this problem: http://www.freedesktop.org/wiki/Specifications/icon-naming-spec/to-be-named Personally, I think forking the spec might be the best idea. Richard. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What is the definition of standards?
On Mon, 2008-12-01 at 20:09 +0100, Jakob Petsovits wrote: Although, didn't someone propose a distinction between specifications that have generally been agreed upon, and specifications that have not? The Specifications wiki page should have that already, listing the specifications in such groupings. -- Rodney ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Why .local/share ?
On Wed, 2008-11-12 at 11:10 -0500, Liam R E Quin wrote: Certainly nowhere starting with a . -- I don't want to be carrying binaries around in hidden directories in 10 years' time. Luckily the world is going to end in ~4 years, so we won't have to worry about what the convention is 10 years from now. Granted, if we're still doing a lot of the stuff we're doing now, in 10 years, we have failed anyway. I hope $HOME will be much less important in much less time than that. The desktop is at a point where it's really only useful for hackers and data entry personnel any more. It's not the best interface for games, music, video, or lots of other activities. -- Rodney ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Why .local/share ?
On Mon, 2008-11-10 at 11:30 +0100, Thiago Macieira wrote: Orion White wrote: Hi-- I've begun to use the XDG base directory standard for my projects, and I am very happy with it. However, I do not understand the rational behind .local/share. I have searched the Internet for some explanation, but to no avail. Why is .local/share not just .local/ or .share/? Why the two levels? And what is supposed to go in .local/ other than share/? Think of .local/lib, .local/bin, .local/libexec or .local/include. Also note that many systems already append share to their prefixes (/usr, /usr/local), so it was probably easier to reuse the code. Then why .config instead of .local/etc and .cache instead of .local/var/cache? Shouldn't these directories be under .local as well? And shouldn't we define XDG_FOO_HOME variables for the other paths? I think an $XDG_LIB_HOME would be particularly useful for apps who wish to allow plug-ins to be installed in the user's home directory. -- Rodney ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon theme spec on the website
The details are in the spec. The problem with file type icons is people assign arbitrary things as the MIME type. Like application/foo for audio files, or text types. It seems like most new things just end up under application/ when they would be better suited to other groups, or perhaps should have new sane groups created. There are very few types for which application actually makes sense as a grouping. Having these sorts of types defined, makes it very hard to easily fall back to a sane generic icon. This is why the new generic icon stuff was added to the Shared MIME spec, and is in shared-mime-info now. The icon-naming-utils package is and always was meant as a crutch, to help us move forward, without sacrificing compatibility in the meantime. It is not a hack, but a temporary bandage to help with the insane number of icons we have in the desktop. So, I'm not quite sure what you mean by having battled with ridiculous icon names or anything. I've never seen any e-mail from you on this list, the tango list, or personally, asking for clarification where you might be confused with some wording in the spec, or to propose new icons, or anything. And it is rather insulting for your first e-mail to be one of such bold insistence that the spec needs a re-think and serious additions and rules, and still yet you have any to propose. If you have something to propose, then do so. Don't lurk in the background and wait for an opportunity to complain. Propose it, and there can be discussion and acceptance or denial of your proposal as is fit. Making rash demands without any supporting information, is not making a proposal. -- Rodney On Thu, 2008-09-25 at 23:06 +0800, Toma wrote: Agreed. Too long have I battled with ridiculous icon names. Over in E town, we're trying to get the icon themes to provide icons for the file manager, but the majority of icon themes use hacks and links to get them to work with a particular version of whatever. Now, you can blame this on the icon packager, but part of the blame is in the spec, for not outlining all the details. That said, the whole spec needs a re-think and needs some serious additions and rules. Toma ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon theme spec on the website
On Thu, 2008-09-25 at 15:38 +0100, Richard Hughes wrote: On Wed, 2008-09-24 at 11:30 +0200, Stephan Arts wrote: I noticed system-suspend system-hibernate and system-reboot are missing from 0.8.90, is that is CVS? I've given up on the icon-naming-spec, it's just too hard for developers to get dobey to add new icons without a massive flame-war. It's not that hard. You just want to make it hard. When I asked for more details in support of adding the system-software-installer icon (which you simply *demanded* be included, rather than subtly proposed), all I got back was you ranting about how *hard* it is to get an icon in the spec. I'm sorry, but if asking for supporting evidence is somehow the start to a flame war, then something is seriously wrong, and it's not on my end. I think the crux of the problem is that some people see the icon naming specification as a shared specification so that applications can have shared icon names, and other people see it as the minimum list of icons you have to draw in a theme. No. The problem is that there are people who expect the spec to be a list of icons to use, and that's it. And what's what you're expecting it to be. The simple fact is, and I have stated it several times since I first wrote the spec, is that it is meant to be both a minimal list of icon names that need to be provided to theme the *DESKTOP, as well as to provide the guidelines for naming icons as extensions to those in the spec. All applications may not necessarily be part of the desktop. And just as impossible as it is for applications to always depend on the absolute base set of icons at all times, it is impossible for any single spec to provide a list of all possible icon names. The real problem is that too many applications have too many icons that they don't actually need, but the developers are so insistent that they must be there. I have no problem adding useful, good icons to the spec. But I won't just sit around all day taking your *DEMANDS* and obeying them. I don't have a lot of time to maintain the spec. I don't get to hack on whatever I feel like all day, and get paid to do so. Were I to, perhaps I could concentrate more time on the spec. Until then, I don't have time to deal with demands. If you want to make rational proposals, and aren't opposed to having rational discussions in order to provide supporting arguments, and to deal with supporting counter-arguments, then I am by all means open to responding to those e-mails and updating the spec to include icons, given that rational discussion suggests it best to do so. Also, it has always been the intent to create addendum specifications which list standardized icon names for other specific genres of applications. For example, I have already started on a standardized list of device icon names[1], though it is only a .txt file currently, and not Docbook. There is absolutely no reason this can't also be done for Development Tools or Graphics Tools as well. The only thing preventing that, is nobody else wants to take the time to do it, and I don't have the time to do it. Thanks, Rodney [1] http://people.freedesktop.org/~dobey/device-names.txt ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon theme spec on the website
On Thu, 2008-09-25 at 21:05 +0200, Jakob Petsovits wrote: And a staging area. Like, a place where developers can list their icons regardless of applicability in other desktops, and other devs list theirs too, and everyone can have a look at what similar applications use and consequently agree on a single naming set. You mean like the Missing Icons List and Additional Icons bits on the icon-naming-spec wiki page [1]? I think Diana Fong created these a while back, but they never went anywhere, because she left Red Hat, and nobody else ever pays attention to the wiki. It's obvious you didn't look there, for example. And I can't force people to use it. I believe a major problem is that the desktops just don't know of each other, and use whatever non-standard icon names they can just think of, even if the other desktop has already done lots of thinking about this issue and might have a sounder solution. If we want people to work together on icons, we should know what the other's icons are and how they can be made to fit into a single scheme. And when people agree on a given name and description, they should go into the spec. I don't think it's a real problem. The whole purpose of the spec was to solve this. And I think it's doing fairly well now. KDE 3.5 was obviously a big problem here, but nobody ever wanted to change it to follow the spec, because everyone was waiting for KDE 4. I wanted to throw up a website to facilitate this for a long time, but it just never fit into my schedule. Maybe someone likes the idea and feels motivated to help the devs come together for icon naming and more detailed usage descriptions :] See the wiki which we already have. All you need to do is use it, and get other people to use it. This stuff needs to happen on freedesktop.org, not on kde.org or somewhere else. I also believe that an icon naming specification should not aim to have developers rethink how their application works, which is what dobey also tried to do with the spec. How interfaces are designed is subject to a given desktop and its user interface paradigms and HIG, trying to force a specific way of working onto the other desktop is imho something that slowed down icon adoption. No, it's not what I tried to do with the spec. I tried to facilitate the lowest common denominator. If some desktop really thinks they need to provide significantly more icons in the base theme, and that any theme designed for that desktop needs to provide those icons as well, there is nothing preventing that from occurring. But such requirements are not a part of this spec, and are the responsibility of the desktop. The spec provides guidelines for naming those icons, and hopefully those icon names will be derived from ones in the spec, facilitating the fallback mechanism which is described there. What slowed adoption of the naming spec in KDE was several developers and users conflating the icon naming spec, and the tango icon theme, as well as the fact that nobody wanted to change KDE 3.5, and instead were working on other aspects of KDE 4 than icons at the time. Anyways, let it be bottom-up, not top-down. Desktops and applications use their own icons anyways (if they can find artists drawing those, at least), and won't stop doing so just because the extremely limited set of icons in the spec doesn't cater to their needs. We should try to find similarities where those already exist, and only cut down on icons when a solution can be reached that everyone is comfortable with. Again, as I've said several times. The naming spec is the lowest common denominator, and the minimal set of icons a theme should provide. Adding ever possible icon that does exist, or may exist in the future, is just not plausible, if we ever want to call it a 1.0 spec. What can be done, however, is for more specific icons, suited to more specific applications, to be defined in addendum specifications, such as the device names addendum which I have mentioned several times. My opinion is that a fixed set of icon definitions will never suffice for all the different usages there are. Let the icon naming spec be replaced a publicly editable list of which icons exist and where / how often those are used. Themers do one icon at the time anyways, so they could just pick the next one on such a priority list until they lose motivation (one could also say until they're done, but complete icon sets covering all desktops and applications don't exist and are mostly a utopian wish, imho). No. A fixed set will never suffice. And you will never finish writing a set of icon names if all you ever want to do is make a list of icon names that could possibly be shared across multiple applications. We don't need to replace the spec. We need to either get me more time to work on the spec, and creating addendum specs, by somehow employing me to do so, or you need to get people to get off their own asses
Re: Icon theme spec on the website
Do you know of some way to make the -latest.html link get generated from the spec in cvs, rather than just pointing at the latest version that was released? There hasn't been a release since the 0.8 version of the spec. I suppose I can make an 0.9 version if there is some immediate pressing need to do so. -- Rodney On Tue, 2008-09-23 at 14:11 -0700, Bastien Nocera wrote: Hey Vincent, Could you (or any authorised person), please update the icon naming spec on the website: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html It doesn't look like the spec on the website has been updated for 2 years... Cheers ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon-naming-spec names help... (I am a bit confused)
Hi, On Mon, 2008-09-22 at 16:41 +0200, Stephan Arts wrote: gnome-fs-blockdev gnome-fs-fifo gnome-fs-socket gnome-fs-chardev gnome-fs-regular As you can see, I found replacements for the top 7 icons pretty easilly. But the last 7 confuse me, which icon-names should be used for that? There are no replacements for these in the spec. A regular file icon doesn't make sense, as every file should have a mime type. It was used in nautilus for text file previews, and we have text-x-preview in gnome-icon-theme for that, but it is not in the spec, and I don't think it should be. If you really care to have icons for the other special files, you should be able to name them like inode-chardev as their mime types are inode/foo. The Icon Naming Spec says specific mime type icons should be named the same as the mime type, replacing / with -. -- Rodney ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon-naming-spec names help... (I am a bit confused)
On Mon, 2008-09-22 at 11:03 -0400, Matthias Clasen wrote: On Mon, 2008-09-22 at 10:56 -0400, Rodney Dawes wrote: Hi, On Mon, 2008-09-22 at 16:41 +0200, Stephan Arts wrote: gnome-fs-blockdev gnome-fs-fifo gnome-fs-socket gnome-fs-chardev gnome-fs-regular As you can see, I found replacements for the top 7 icons pretty easilly. But the last 7 confuse me, which icon-names should be used for that? There are no replacements for these in the spec. A regular file icon doesn't make sense, as every file should have a mime type. It was used in nautilus for text file previews, and we have text-x-preview in gnome-icon-theme for that, but it is not in the spec, and I don't think it should be. Thats just really not true. A generic file icon makes a ton of sense. You don't always want to represent mime information. Please provide a use-case where it makes sense. The ONLY case I've seen where it makes sense, is for the text preview in nautilus, and the text preview is not at all useful unless you get a 300+ dpi screen and use icons that are = 128px in size. And since the icon theme can't specify what font metrics to use for it, there's also styling issues with it. The only thing the icon theme can specify, is the rectangular area to stick the preview text in. But if you have some other viable use case, I would love to hear it. -- Rodney ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: missing a .desktop files howto
On Thu, 2008-09-04 at 17:53 +0200, Matej Tyc wrote: Hello, I am developing an aplication that could use a menu entry. I have learned that I have to drop an appropriate .desktop file to /usr/share/applications, but I have problems with icons. If I write Icon=foo, then where to put the actual icon? As per the Icon Theme Specification and the Icon Naming Specification, your icon name should match the binary name of your application, and be installed in the hicolor icon theme's apps context directory. /usr/share/icons/hicolor/48x48/appname.png /usr/share/icons/hicolor/32x32/appname.png /usr/share/icons/hicolor/22x22/appname.png /usr/share/icons/hicolor/16x16/appname.png These are the most important sizes to provide with your application. Anyway, I don't understand where people get those information and how come that there are so many things in menus since it is so hard to find a howto :-) Really, I have searched quite a lot and I wasn't able to find a user friendly guide... And does anyone here have any experience how to install .desktop files using autotools? There are multiple ways to do this, depending on how you are translating the .desktop file, if you even are at all. You can look at almost any GNOME application to see how it is done when using intltool to handle your translations. It's basically something like: desktopdir = $(datadir)/applications desktop_in_files = appname.desktop.in desktop_DATA = $(desktop_in_files:.desktop.in=.desktop) @INTLTOOL_DESKTOP_RULE@ If you're not translating at all, then the following is sufficient: desktopdir = $(datadir)/applications desktop_DATA = appname.desktop -- Rodney ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: missing a .desktop files howto
On Thu, 2008-09-04 at 11:28 -0500, D. Marlin wrote: Matej Tyc wrote: Hello, I am developing an application that could use a menu entry. I have learned that I have to drop an appropriate .desktop file to /usr/share/applications, but I have problems with icons. If I write Icon=foo, then where to put the actual icon? I'm not an expert on this, but one location where you can place an icon is in $PREFIX/share/pixmaps, i.e.: /usr/share/pixmaps/ You'll find a lot of icons there. As I understand it, there are alternate icon locations that make up the search path, including paths for themes, but I don't know the full search path right now. Maybe someone else here can clue me in. ;-) The pixmaps directory is deprecated in favor of icon themes. See the Icon Theme Specification (and the Icon Naming Specification). :) -- Rodney ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon names vs. emblems
On Tue, 2008-06-17 at 09:14 -0400, Matthias Clasen wrote: On Tue, 2008-06-17 at 12:35 +0200, Jakob Petsovits wrote: As long as providing such a [base]+[emblem] icon is always optional for the icon theme, this might work out nicely. I think the language in your patch is not optimal yet, it should emphasize that this is mainly a feature for themers to provide tuned versions instead of the standard overlay mechanism. Sure, thats the intention. I can rework the language to make that clearer. How is using a + any different from a - in this situation? Shouldn't we provide the icon, and the emblem (in their appropriate contexts), and the implementation then do what it needs with them? Why wouldn't the implementation just load the icon and the emblem, and overlay them in code? We already do this in nautilus for numerous file properties anyway. Perhaps now would be a good time to implement some sort of emblem API in the icon theme implementation, and update the Icon Theme spec to clarify the Emblems context a bit. In the GIcon/GtkIconTheme case, it might be a good idea to add some sort of list of emblems for the icon. This way the emblem could be loaded and composited automatically in the right place. -- Rodney ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [icon naming] zoom vs. page-zoom
On Thu, 2008-05-29 at 06:45 -0700, James Richard Tyrer wrote: Rodney Dawes wrote: That would be like having user-trash, user-bookmarks, user-online, user-desktop, and whatever else there might be, fall back to user. Not very sensible at all is it? No it isn't very sensible because the icons in your example should be named: trash-user, bookmarks-user, user-online (this one is correct), and bookmarks-user, we aren't going to worry about user-online since it will work either way, and desktop-user would fallback to desktop So this is perfectly sensible. Your solution is sensible if you ignore the very precept of the Icon Naming Specification, which is that the list of icons contained therein, is the absolute base list of icons, and everything else should fall back to something within the spec itself. Note: I really like the new icon naming system. However, I am starting to wonder if those that invented it really understand it. :-D As per your comments, I would suggest that the misunderstanding is in fact, not on the creator's end. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Commit notifications for specs
On Sat, 2008-04-26 at 15:55 +0200, Vincent Untz wrote: Hi, I've asked for the creation of a git repository to host all fd.o specs (will make things much easier). I think it'd make sense to send commit notifications to this list since it will help people track the progress and the changes. What do people think? I would prefer to not have my spec moved to a git repo out from under me. I much prefer the work flow I have currently with CVS. SVN would be ok, but GIT has a very different work flow, and doesn't seem to suit the process of simple spec maintenance as well. People should not be maintaining forks of specs in private repositories. An obvious alternative is to create a new list, of course. I think a new list would be best. It could get noisy for new specs which are undergoing lots of changes. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: desktop neutral xsettings manager?
On Wed, 2008-04-23 at 22:49 +0800, 洪任諭 wrote: No, lxsession and lxsession-lite don't do that. lxde-settings, however, map a simple config file with ini format to xsettings for LXDE. Besides, xsettings is NOT practically desktop-neutral. Currently only GTK+ programs use it. Not true. No other toolkits or desktop environments support this. I am pretty sure that Xt and Qt/KDE both support it. Also, the config values supported by gtk+'s xsettings can be set in gtkrc file. Yes, because GTK+ != GNOME. So, for a gtk+ only desktop, there might be no point in using Xsettings. Sure there is. The reason gnome-settings-daemon exists is exactly because of this. Not every GTK+ app reads values directly from gconf. However, with GNOME, many settings are stored there, and non-GNOME apps need to use them as well. So, gnome-settings-daemon specifies the font information, and other settings, via Xsettings. This is why in GNOME, the font in GIMP, Inkscape, and other apps, is the same across the board. This is the current status of that gtk+ only spec. XSettings is not a gtk+ only spec. GTK+ might be the only toolkit that makes extensive use, and extends it for its own settings as well, though. So, we cannot expect too much now. Sure we can. The only issue is that we need a cross-desktop configuration solution also. Otherwise, you're going to need to have the cross-desktop xsettings daemon read config values from various places, and magically try to merge them into one value. -- dobey 2008/4/23 Patrice Dumas [EMAIL PROTECTED]: On Wed, Apr 23, 2008 at 12:53:41PM +0200, Patrice Dumas wrote: Hello, Are you aware of a desktop neutral xsettings manager, like http://www.freedesktop.org/wiki/Software/xsettings but which would actually look at a config file and stay in the background? I have found lxsession and lxsession-lite which seems to do that. -- Pat ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Desktop Theme Spec
On Mon, 2008-04-21 at 03:09 +0800, 洪任諭 wrote: 2008/4/21, [EMAIL PROTECTED] [EMAIL PROTECTED]: 洪任諭 wrote: We should have only one set of common theming API for all toolkits. Then some backends for every toolkits should be created by the developers who master these toolkits. When you have a common theming API, you have a common theme, too, isn't it? Is a common API the only way? What do you mean with API? An API in hundert veriants of languages? An common daemon? Everthing is bad. So just use an comman theme format. We are talking about totally different things. Having common theme format doesn't give you common themes since most of what you saw in every themes are drawn with code, not defined by files. If two pieces of code draw the same format differently, there is a bug somewhere. That's like saying KDE and GNOME are allowed to render SVG, HTML, PNG, or any other displayable format, differently, and it's OK. But we all know that's not how things work, and it isn't true. Having common format to define colors / pictures / fonts is far from having common themes. The underlying theme engines need to be re-designed. They need to be destroyed. Theme engines are one of the worst things we have. It's very hard for artists to design a theme, when they don't know how to code, if they have to write an engine. If you don't understand what I said, maybe you can take a look at the source code of some gtk+ theme engines and some Qt ones. Then you'll know why I said this. I don't understand what you've said, and I've written a theme engine, and worked on several others. SVG is almost what we need for a common theme format. It's a bit off from what we need, but it's quite close. What we need is something similar to SVG, but where x/y/width/height/etc... are dynamic, and specified at render time, so that we can have truly scalable art in our themes, and we can eliminate the need for writing code to theme toolkits. If you really just want a cross-toolkit API for theme engines though, perhaps you should take a look at the metatheme project. I think it is/was hosted at http://metatheme.cx. I don't know what is up with it, but that is exactly what the project was working on. Of course, either of these solutions have the drawback of not being able to make significant changes to existing widget behavior/look in the theme, as you can now with the toolkit-specific engines, by manipulating widgets directly. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Desktop menu - new category
I would vote for having it be either Philosophy or Theology. -- dobey On Wed, 2008-04-16 at 14:57 +0200, Vincent Untz wrote: Le lundi 14 avril 2008, à 21:47 +0800, Toma a écrit : Well there is a growing number of Religious software about and it should have a home in the menu. Its a matter of organisation and not about making people happy. Personally, I hate tidying up but its got to be done. :) Having a registered category doesn't mean the category will appear in the menus. You'd still have to convince the people shipping .menu files that there's should be a submenu for this category. Its better than having someone have their software file its menu item under Office or Accessories (or my beloved Games!) Having said that, Religious get my +1 Religious is an adjective. As far as I can tell, nearly all categories are nouns (or actions, like Printing, Scanning). So, not a good option, IMHO. Vincent ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Desktop menu - new category
On Thu, 2008-04-10 at 23:31 +0200, Jakob Petsovits wrote: On Thursday, 10. April 2008, Aaron J. Seigo wrote: On Thursday 10 April 2008, jmehdi wrote: Hi Mehdi, Out of curiosity, what software are you thinking of having in there? :) Softwares used to study the Quran and Hadiths (words of the prophet Muhammed), to display prayer times, to display du'a (supplications) etc. there are also similar applications for the Christian faith (e.g. BibleTime) that would probably fit into the same category. Just a minor note, but still... I'm wondering which menu icon metaphor would be appropriate for a set of applications that covers very different and mutually exclusive world views. Actually, the globe icon would probably be best for this, while some other icon would be much better for Network/Internet, as this actually has to do with the view and creation of the Earth, where the Network/Internet categories have nothing to do specifically with the Earth, aside from the fact that all current users of it, originated here. :) -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon naming issue
On Fri, 2007-04-27 at 22:34 +0200, Kenneth Wimer wrote: On Friday 27 April 2007 21:39:48 James Richard Tyrer wrote: Patryk Zawadzki wrote: HiColor is not default, it is fallback. Semantics Failing to follow the semantics of a specification means you fail to follow the specification. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon naming spec suggestions - mimetypes
On Fri, 2007-12-28 at 23:14 +0100, Jakob Petsovits wrote: On Friday, 28. December 2007, Jan Claeys wrote: Op woensdag 26-12-2007 om 01:02 uur [tijdzone +0100], schreef Jakob Petsovits: application-x-zerosize The icon used for empty files. Why do those need a different icon? Well, I wouldn't consider any other mimetype icon to be appropriate for empty files. Imagine a file manager that displays the text-x-generic icon for an empty file - this indicates that the file has contents, which is misleading. Are there any examples of file managers (or file listings, like in the file-open dialog) that do not use a separate icon for empty files? So then again, how is that different from unknown? If there is no content, how can you determine the type of content? Generally file managers guess the content type from the extension after looking at the content. If the file extension is .txt, it is acceptable to presume that the user wishes to insert text into the file, I think. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Fwd: Question on icon theme
While having a list of icons that are not in the base specification is great, I don't think we should list icons as a per-desktop thing. The goal of icon themes, and the naming spec in particular, is that we can use the same icons on all desktops. I would much prefer the addendum specifications to be targeted at more specific tasks, or goals. For instance, the Device names addendum I've already started on is to list all the icons for specific devices, so that we can more accurately represent devices that are connected to the computer, in the desktops. Some examples of task-based addendum are: - Programming - Graphic Design - Data Management - Device Icons - Audio Production - Video Production - Video Game Emulation All these represent needs the various desktops have. I think it would be a waste to have to duplicate these lists over and over for every desktop out there that gets put on the wiki. So can we please change to using this method of icon classification? I think it better suits the purposes of FreeDesktop.org and the Icon Naming specification, as well as what the goal of this proposed process. -- dobey On Wed, 2007-12-12 at 11:27 +0100, Christopher R. Parr wrote: Apparently anyone can create pages. See http://www.freedesktop.org/wiki/Specifications/icon-naming-spec/desktop-icon-lists?action=show Christopher ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Fwd: Question on icon theme
The ones I listed are just examples. I've already got much of the Devices list taken care of through a text file on my fd.o space[1]. I'm sure there are plenty more that would make sense as well. The Graphic Design is also partially taken care of through the Tango Art Libre page[2], but we should probably move it over to fd.o. Also of interest is probably making a list of deprecated[3] icons which are still in use but we want to encourage people to move away from using in their applications. This list is currently very minimal and we haven't put a lot of time into filling it out yet. It would be great if we could get work done on that front as well. -- dobey [1] http://www.freedesktop.org/~dobey/devices.txt [2] http://tango.freedesktop.org/ArtLibreSet [3] http://tango.freedesktop.org/TangoDeprecated On Wed, 2007-12-12 at 17:52 +0100, Christopher R. Parr wrote: That's an excellent point. If you want to, I can add the pages in the wiki. Please let me know which other areas are needed. Christopher 2007/12/12, Rodney Dawes [EMAIL PROTECTED]: - Programming - Graphic Design - Data Management - Device Icons - Audio Production - Video Production - Video Game Emulation ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: locale specific for .desktop
On Thu, 2007-10-18 at 17:55 +0900, Takao Fujiwara - Tokyo S/W Center wrote: Some of the applications are used on one locale only, e.g. Chinese dictionary application, Japan road map application. The situlation is, those applications are used for one country only, the native persons require to show the application by default, the native person usually uses one locale only. But we don't have suitable applications for all locales so the .desktop needs to be shown on one locale only. No app should ever show for only one locale. I have friends that live all over the world. I would want to see a map application, or dictionary, no matter what. If the application does not have sufficient translation to other languages, that is a problem with the application, not the user, the user's environment, the XDG specs, or anything else. If your problem is you lack translations, then you should make the translation department at Sun fix it, not the XDG Desktop File spec. IMHO installing multiple .desktop files for an app (e.g. 1 per language for some number of languages) is foolish, and just slows down menu implementations. The app itself should deal with the locale appropriately by examining environment variables. Personally, I'd prefer we didn't add complexity to the spec when the same functionality can be handled outside it. The problem is we don't have any way to handle this case. We do have a way to handle it. It is called packaging, and system lock-down settings. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: locale specific for .desktop
I have to agree with Matthias here. Icons should a) be in the theme, and b) be in US-ASCII. The prior part is specified in the Icon Theme Spec, and the latter in the Icon Naming Spec. An application's icon should be named the same as the binary which is run to use the application. The behavior is undefined where this is not the case. -- dobey On Tue, 2007-10-09 at 22:17 +0900, Takao Fujiwara - Tokyo S/W Center wrote: I think users want to use their icons and it depends on each user whether they use the simple icon names or not. I'ld like to know how to conver the user's behaviors in the specification but not the each case. Or do you mean we can avoid this case in each implementation, e.g. launching a dialog? Matthias Clasen wrote: On Tue, 2007-10-09 at 22:03 +0900, Takao Fujiwara - Tokyo S/W Center wrote: #3. Filename encoding. What should I do to save the icon filenames with other encodings in UTF-8 .desktop files? Can we put escaped URI strings instead of the native local paths? The best solution is to simply use icon names that are making this unnecessary. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: locale specific for .desktop
On Tue, 2007-10-09 at 21:25 +0200, Patryk Zawadzki wrote: 2007/10/9, Thiago Macieira [EMAIL PROTECTED]: Patryk Zawadzki wrote: 2007/10/9, Takao Fujiwara - Tokyo S/W Center [EMAIL PROTECTED]: I think users want to use their icons and it depends on each user whether they use the simple icon names or not. I'ld like to know how to conver the user's behaviors in the specification but not the each case. Or do you mean we can avoid this case in each implementation, e.g. launching a dialog? Use the UTF-encoded name and recode it to filesystem encoding when searching for the file? Different filesystem can use different encodings for file names across one system. Sorry, but that breaks if the locale somehow changes. If what changes? I currently use UTF-8 encoded locale while saving data to a ISO-8859-2 encoded USB stick. For each path segment check the charset used by said directory (if on a different mount) and parse next segment accordingly to that. This should work. File name encoding is not guaranteed to be in a specific encoding. You can have file names in several encodings in the same directory on the same file system in Linux, at least with ext. If the user's encoding changes, and the file name encoding does not match that, or the system default, there's no guaranteed way to know what it is. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: locale specific for .desktop
On Thu, 2007-10-04 at 18:52 +0200, Sanel Zukan wrote: There are a number of locale specific problems for .desktop spec. #1. Language specific launcher options. I'ld like to switch the command options by languages. E.g. Name=Document Exec=gnome-open file:/usr/share/doc/foo/C/index.html Exec[de]=gnome-open file:/usr/share/doc/foo/de/index.html Exec[fr]=gnome-open file:/usr/share/doc/foo/fr/index.html How about locale executions? This proposal has it's place, but here is mine -1 for it :) IMHO this opens a huge door for more abuse for Exec key, so anyone could place something like: Exec[de]=/usr/local/bin/foo Exec[fr]=/usr/bin/baz which creates inconsistency. Already hearing people asking why their German colleagues opens this but they are getting that. Hm... just thinking, could some shell script resolve this ? The only viable reasons for this that I can see, are documentation, and document templates. The former is solved by integrating the documentation into the help system. The latter should be solved by the application opening an appropriate per-language template if necessary. AbiWord does this already for example. #2. .desktop could be shown on a locale only. I'ld like to show a locale specific application on the locale only in gnome-panel menus. E.g. Name[zh_CN]=Application Name Comment[zh_CN]=Application Comment Exec=/usr/bin/zh_CN-application How about removing C Name? Why would the C name need to be removed? Isn't this the same as above? The feature isn't. The implied suggested implementation is. The better solution for this would be an OnlyShowInLang, that is similar to OnlyShowIn for desktops. #3. Filename encoding. I'ld like to keep Encoding=UTF-8 but the actual filepath could be several encodings. E.g. Encoding=UTF-8 Name=foo Comment=foo Icon=file:/home/foo/EUC encoding/foo.png How about URI escape sequences? AFAIK, Icon key contains system path, not URI path (wrong ?). On other hand if you already using URI path (and application understainds it), at least for me, escape sequences comes naturally :) Icon really should just be a name, and the icon should be looked up through the icon theme API. If one is going to put a URI in the file, and it points to something that is in a non-ascii encoding, it must be escaped, according to the RFC AFAIK. Doesn't the URI RFC require that the encoding be US-ASCII? Either way, if you specify an encoding, and then have data in another encoding, it's going to break, as there's no way for the implementation to know what encoding the alternate is. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Category for a desktop tool needed
On Fri, 2007-08-10 at 15:59 +0200, Stanislav Brabec wrote: Rodney Dawes wrote: On Fri, 2007-08-10 at 13:10 +0200, Stanislav Brabec wrote: Rodney Dawes wrote: This would also solve the Accessibility issue that Stanislav brought up in his mail, wanting a category for something that provides an additional service, but isn't a standalone app 'window'. It still does not solve the problem, which secondary category fits the application (Service), which simply makes desktop more usable. makes desktop more usable is a subjective measurement, in this example, not objective. I want Utility;Desktop, not Prettification. Something targeted to desktop itself. Want to use it for what? So far nobody has explained what exactly the category needs to be used for. You've just declared a need for a different category. Makes desktop more usable or application which helps to organize windows is maybe a subjective measurement. But please show me to a correct secondary category for it in the current specs. Tell me what I am trying to describe, and I will describe it. :) On top of the secondary categories, we also have the reserved categories for Screensaver, TrayIcon, and Applet to use. These probably all fit the type of apps you want to have a new special Prettification category for. It is not Screensaver, TrayIcon nor Applet. What isn't? Desktop Widgets as used by dashboard/gdesklets/karamba are all applets. They are just desktop applets, as opposed to panel, or java applets. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Category for a desktop tool needed
On Fri, 2007-08-10 at 13:10 +0200, Stanislav Brabec wrote: Rodney Dawes wrote: This would also solve the Accessibility issue that Stanislav brought up in his mail, wanting a category for something that provides an additional service, but isn't a standalone app 'window'. It still does not solve the problem, which secondary category fits the application (Service), which simply makes desktop more usable. makes desktop more usable is a subjective measurement, in this example, not objective. The secondary category for a Service would be related to the service it provides. For example, an OBEX FTP service should have FileTransfer as an additional category. Vino would have RemoteAccess. I don't think having additional categories for subjective metrics such as makes *my* desktop prettier for *me* is appropriate for a standardized specification. On top of the secondary categories, we also have the reserved categories for Screensaver, TrayIcon, and Applet to use. These probably all fit the type of apps you want to have a new special Prettification category for. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Category for a desktop tool needed
Dock as in WM dock/system tray? or Dock as in desktop widget/gadget/whatever? -- dobey On Wed, 2007-08-08 at 17:11 +0200, Philipp Thomas wrote: I need categories for a dock type application and its settings tool and non of the available ones seem to fit. After discussing this with a collegue, I'd like to follow his ideas and propose the following: 1) deprecate DesktopSettings in favor of Desktop;Settings 2) add Desktop: | Desktop | Desktop management | Utility, Settings or System | 3) Be more exact about Accessibility ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon name; task-passed-due
On Wed, 2007-07-18 at 11:34 -0700, James Richard Tyrer wrote: I think that proper US English would be past due Yes, the work 'passed' exists but it has a different use. Normally used to indicate that a physical object has been passed: I passed the ball; I passed the car. But, an account is: 'past due'. This might be different in British English. Or, the time when a task is due, has passed. And since past due is a single token, this should be: task-past_due There is nothing in the spec requiring single tokens to be separated with the _ character. It is only stated as one of the allowed characters. However, past due is more correct, and I will rename the icon to task-past-due. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Actions: grouping vs. extensibility
On Mon, 2007-07-16 at 12:23 +0200, Jakob Petsovits wrote: jimmac the major part of that all making sense is the generic type fallback Hi list, yesterday I started to tackle KDE's actions icons for icon naming spec compliance, and I stumbled across a major bug in the spec, so to say, or at least something that will make it impossible for us to comply while still keeping the amount of shared icons in kdelibs that we intend to have. The issue is the grouping of action icons by objects that the action operates on, it conflicts with the concept of levels of specificity and in consequence with sensible fallbacks. Sounds a bit theoretical, let's have an example (the most visible one for that matter): The spec has a series of document-* icons, like document-new, document-open, document-save, and others. The problem with this approach is that there is no generic fallback if I want to create or open something other than a document, say, a project which consists of multiple documents. The specification in its current form just creates a new namespace for the most common items address-book, application, contact, document and window (for the new action), but if we want to put something else into kdelibs (bookmark-new, project-new, tab-new) we'll break the spec. Which is bad. How does foo-new break the spec exactly? The specific action is the more specific part here. Therefore, I demand that the spec is changed as follows: Demand is such a rude word. Suggestions, constructive criticism, etc... are welcome, but demands are not. * Add a new icon The icon for the create action. * Add a close icon The icon for the close action. What will the metaphor be? How will these icons relate to all formats? * Remove the document- prefix from the open, open-recent, save and save-as actions You're misinterpreting the term document here, to mean files formatted for print that primarily contain text, which is incorrect. All of the files a user can view/edit/play/etc... are documents. * Add an edit icon The icon for the edit action. What exactly would this be? Why do we need it? All of the icons under edit-* are for things that normally appear in the Edit menu of an app. * Rename system-run to run I don't see any specific benefit for this. For the icons you mentioned this being useful for, I see the following as better suggestions: run-build (compile the current selection, used in IDEs) project-build run-build-file (compile a single file, used in IDEs as well) project-build-single run-validation (check an XML file for compliance) document-validate (useful for things other than XML) I think these few changes should solve this issue of extensibility and fallbacks. There might be a few other icons that we'll propose, but this specific problem is pretty much a thing of the past if these changes go in. Please don't dismiss this request lightly. We are going to have a lot more icons than the spec demands, and we are going to put a lot of them into kdelibs in order to share them among applications. I don't want to introduce non-compliant icons, but if there's no compliant way to do it then we'll prioritize KDE's needs over specification compliance. Could you help us to achieve both? The spec was never meant to be an absolute conglomerate of all icons for all occasions in all desktops at all times. It is meant to be the base minimum set of icons a desktop should require to maintain visual appeal. The spec is also not 1.0 material yet, and doesn't claim to be. But that doesn't mean that we can change the spec so heavily, for one desktop or the other. It is nearing 1.0, but is still not solid enough to be called such. I don't think the changes you are demanding here are totally necessary, or that there is an extensibility issue. The spec was written with extensibility at the forefront from the beginning, as it was always meant to only include a base minimum set of icon names. As an example of this, see the recent work that has gone on with the device names as an extension to the spec. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Trusted vs Unstrusted MIME types
On Mon, 2007-07-09 at 11:57 +0200, Patryk Zawadzki wrote: On 7/9/07, Rodney Dawes [EMAIL PROTECTED] wrote: One very important design heuristic that should be followed here is Always let the user feel in control. I'd rather word that differently. For me user in control means ignoring any messages and blindly clicking next. Been there, seen that. I didn't say that the user should BE in control. I said the user should FEEL in control. There's a big difference there. If the user keeps blindly clicking next then they aren't in control. They are dismissing the annoyances that make them feel as they aren't in control. If the user doesn't feel like she can control what's happening, the software is going to be an annoyance more than an assistance. Inciting fear with a pop-up stating that a file might contain malicious code, for only a small subset of the possible files that might do so, doesn't actively make the situation any better. It will certainly teach users not to read any popup messages instead clicking allow as they would be unable to have any work done. Exactly my point. All that adding a pop-up dialog will do, is delay the agony that will come along with the malicious data. Why not have magic matches for known malicious data in files, instead of just blanketing whole mime types? It's not possible inside web browsers and generally any software dealing with remote files (and these are the major threat). Sniffing contents might be either impossible (a large file that is either not fully downloaded yet or not meant to be downloaded at all in case the opening application wants to do it by itself) or very expensive (samba, webdav over Internet). Anything is possible if you write the software correctly. We (at least in GNOME) already sniff files as they are being downloaded. I would rather download only part of a large file that has bad data, than waste time for the whole thing, to only later find out it's sending out e-mails to everyone in my address book. If we sniff partial downloads, we can then pause the download and inform the user of malicious files, before everything gets down the pipe, and they trash their system. If we just place the choice of fear on the user always at the start of download, we will either prevent them from getting the data they want, because of fear, or cause them to ignore fear, and just trash their system. Either way, the software is to blame. Doing that would take care of even files we think we might trust, like JPEGs, without being overly intrusive in the UI, when not necessary. The JPEG case needs to be fixed in the application and not in the sniffer. Both would take the same amount of work. All cases need to be fixed. But they can't be guaranteed to be. There is no way to guarantee that all users have all updates at all times. It's just not possible. Because, really, by definition, any file not explicitly created by the user, should be considered as potentially unsafe. And even some files created by the user, should be considered unsafe, because we don't know if the software that created it is safe. That's what I said earlier in the thread. A file that does not originate from my machine is considered not safe. If I use Firefox to save it locally I no longer get any warning about its contents. I think to solve this properly we'd need a new filesystem with more extended attributes that follow the file (think of marked as safe) :) There really is no way to solve this properly. You can't know for 100% whether something is safe or not, until you run it. The absolute best we can do to check for safety, is to sandbox, sniff, and run. If a file marked as safe, is written to by a malicious program believed to be safe, then the file is no longer safe, even though it is marked as such. And presumably to mark something as safe, is something a user must do. At that point, you might as well just do nothing. Malicious users will mark malicious data as safe, if the meta-data is transferable with the file. You then still end up with the problem of having malicious data. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Trusted vs Unstrusted MIME types
On Sat, 2007-07-07 at 09:53 +, Thomas Leonard wrote: How can a type be safe or unsafe? Safeness depends on the application. E.g. a python script is safe if you open it with a text editor, but not if you use a python interpreter. Perhaps applications that are designed to handle untrusted data safely could be flagged as such in their .desktop files? What about trusted applications with security flaws, that handle trusted types? A tar.gz might be considered safe, but could expose a security flaw in gzip. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [kde-artists] Icon Naming: animations/process-working, animations/process-idle
On Thu, 2007-07-05 at 19:27 -0700, James Richard Tyrer wrote: Jakob Petsovits wrote: On Wednesday, 4. July 2007, James Richard Tyrer wrote: I note that the Icon Naming spec includes: animations/process-idle animations/process-working Er, no, the naming spec does not include process-idle. Instead, it says in the description of process-working: The first frame of the animation should be used for the resting state of the animation. So, no need for process-idle, and especially not in animations. You are correct that it isn't in the spec (yet?). It is in the Tango icons. Part of the problem, I guess. Tango and the Icon Naming spec aren't 100% the same. Everything in Tango isn't in the spec, and isn't meant to go in the spec. The process-idle icon is there so we can support the current spinner implementations in GNOME. They expect the idle image to be separate from the animation image. The spec calls for the idle image to be the first frame of the animation. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [kde-artists] Icon Naming: animations/process-working, animations/process-idle
On Fri, 2007-07-06 at 07:57 -0700, James Richard Tyrer wrote: Rodney Dawes wrote: Everything in Tango isn't in the spec, and isn't meant to go in the spec. The Tango group might not agree with that, but anyway. It certainly is starting to look like this isn't going to be simple. The Tango group might not agree with it? Who exactly? Nobody has said anything to me. And I'm the maintainer. If the group didn't agree with it, then process-idle wouldn't even be in the icon theme. The process-idle icon is there so we can support the current spinner implementations in GNOME. They expect the idle image to be separate from the animation image. Yes, that also appears to be the way that Firefox works. It also seems to be how the Oxygen icon developer wants to do it. Why? It seems rather pointless to duplicate a single frame as another image. Firefox doesn't use icon themes, so however it implements themes doesn't affect us. The spec calls for the idle image to be the first frame of the animation. Unfortunately, KDE doesn't fit with either of these. That is, KDE doesn't have an idle image. It cycles through all of the images in the PNG. So, we are going to have to change something in the code either way. :-( However, I think that it would be easiest to conform to the current GNOME system with a separate icon for idle since this would make the: process-working icon the same as our current icon, and we wouldn't have to use the process-idle icon. Uh. KDE fits perfectly with the specification's way of doing it, already. It doesn't have a separate idle image. Fixing the behavior in GNOME is a simple matter of a few fairly simple patches, as there are multiple spinner widgets in use. Nautilus and Epiphany are the ones that stand out in my mind right now, but there may be others as well. As far as KDE is concerned, I don't know what the code looks like exactly, but as I was looking through the images to see how it works, I found just the one multi-frame PNG image for the animation. I really don't understand why you would suggest making the implementation mimic the current GNOME code, and then state you wouldn't need the process-idle icon. That's highly contradictory. If you don't want to show anything for the idle state, then KDE needs to do nothing, except to use process-working rather than the current icon name, as you claim KDE is already showing no image for idle state. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Direction arrows.
On Sat, 2007-06-23 at 23:10 -0700, James Richard Tyrer wrote: The Icon Naming Spec currently lacks icon names for the last two. Should we call these: view-previous view-next of are there better ideas? media-skip-backward media-skip-forward ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdg-utils xdg-icon-resource's destination icon name
On Mon, 2007-06-18 at 11:48 -0700, James Richard Tyrer wrote: IIUC, we are currently working on an icon naming standard: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html KDE will use this standard for the icon names in KDE4. I don't know what GNOME's plans are. When both KDE and GNOME use the same set of icon names, the desktop icons will no longer be isolated from each other by means of the icon names. It seems obvious that users wanting a consistent appearance for their desktop will choose to use the same icon theme for KDE and GTK applications. It is then that there will be issues. Those are the issues that need to be solved. GNOME and GTK+ already support the naming spec to an extent. The MIME type names, for example, are looked up with the naming spec names, being the preferred method, and then falling back to the older gnome-mime prefixed names. This of course, doesn't solve the issue of allowing apps to install custom MIME type icons. However, as previously stated in several threads, Alex Larsson has made a proposal [1] to improve the way MIME icons are specified, and looked up, which very few people replied to. I would recommend you read the archives and start a new thread to give feedback on that proposal. -- dobey [1] http://lists.freedesktop.org/archives/xdg/2005-December/006018.html ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [Icon Theme Spec] Directory Layout
This bug is about GTK+ theme paths, not Icon Themes. The argument of GTK following the Icon Theme spec is irrelevant here. -- dobey On Sat, 2007-06-16 at 09:53 +0200, Stephan Arts wrote: Hi, I am sending this mail in response to this bug[0], regarding the lookup if themes and icons inside the home directory. The spec describes that apps need to search in $XDG_DATA_DIRS/icons, and $HOME/.icons (according to the spec: 'for backwards compatibility'), but not in $XDG_DATA_HOME/icons. If $HOME/.icons only exists for backwards-compatibility, then user-installed themes and icons should be located in $XDG_DATA_HOME, right? Regards, Stephan [0] http://bugzilla.gnome.org/show_bug.cgi?id=447840 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon naming issue
On Sat, 2007-04-28 at 09:33 +0200, Kenneth Wimer wrote: On Saturday 28 April 2007 08:03:27 Rodney Dawes wrote: On Fri, 2007-04-27 at 22:34 +0200, Kenneth Wimer wrote: On Friday 27 April 2007 21:39:48 James Richard Tyrer wrote: Patryk Zawadzki wrote: HiColor is not default, it is fallback. Semantics Failing to follow the semantics of a specification means you fail to follow the specification. Ok, someone show me where it says that hicolor should be a full-blown theme of its own. Re-read Patryk's statement to which you replied simply Semantics. It does not say that hicolor should be a full-blown theme. Nor does it say that it should not be. It merely states a clarification between default and fallback. And in reply to this and at least one other portion of his mail, you simply attempt to dismiss the statements as semantics. I was merely stating that doing so is inappropriate, as a specification is nothing more than a large list of semantics which must be followed, for one to follow the specification. Trying to simplify the issue as semantics reads as one of I don't care or I don't understand but it is unclear which one is the appropriate statement. In either case of one calling hicolor default or fallback the specification uses the term fallback, and to imply that something is a theme, and that applications can fall back to it, is to imply that it does in fact contain icons. If you read the Icon Theme spec carefully, you should also see that it was written with the intent of only sharing application icons which show up in the Programs menu, and not every icon which may appear in an application. However, given the evolution of the desktops to provide themable icons throughout an application, it only seems appropriate that there needs to be a fallback theme which provides all the icons in the Icon Naming Specification, that applications may fall back to. In GNOME, that theme is currently the gnome-icon-theme package. We fall back to it, immediately before the hicolor theme. In KDE 3.x, that theme is CrystalSVG, but the implementation is a little different. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon Theme spec question
On Mon, 2007-01-29 at 18:19 +0100, David Faure wrote: On Monday 29 January 2007, Brian Mattern wrote: Would it make sense to require $XDG_DATA_DIRS/pixmaps as an additional fallback to handle installations outside of /usr? We added this directory in kde's implementation recently, but it's still only a gnome-compatibility hack... Wouldn't it make sense to fix gnome instead, in order to reduce the number of directories that must be scanned? ;-) I don't think this is GNOME-specific. If someone installs a third-party application, or an older application that is not updated to provide icons in multiple sizes and everything for the specs, and that someone wants to install it in a different prefix, you're going to have the same issue, whether the app uses QT, GTK+, or some other toolkit. The spec really should say $XDG_DATA_DIRS/pixmaps for compatibility. The only real way to minimize the number of directories that get scanned, while being able to load all of the icons, is to ensure that as many packages as possible, get updated, and remain up to date. The alternative solution of course, is to just remove that directory from the spec, and tell implementations to not look there, and break many existing configurations, and try to force people to update to follow the spec. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdg-utils xdg-icon-resource's destination icon name
On Wed, 2007-01-17 at 15:50 -0800, Daniel Yek wrote: What kind of response were expected? Response from desktop implementors? Or Software Vendors? People subscribed to this mailing list. Preferably people involved in the development of applications or libraries that implement the specs in question, and the people working on the specs. Basically, it just needs some people to look over it and say yay or nay, and why. By looking at the documentation, I think the Portland Project was trying to promote the use of the scripts so that in the future, the distributors can change the script and have different actions happening in, then, existing released software packages. This is done by having new system-wide xdg-utils scripts in the path overriding the bundled scripts (appear later in the path). So, even though the existing scripts are resulting in a mess, but once desktop implementations change, the scripts can stop creating a mess. Sounds like a plan to me and thus its usage can be encouraged. I suppose that will work later, if the future scripts actually go through and fix things that previous scripts may have done. However, it doesn't help with having the problem of conflicts now, which is where we're at. The longer we wait to fix the real issues, the more problems we are going to have as side effects because of it. My personal/professional recommendation would be to not install the icons in that manner. If others are going to still encourage the usage of the scripts in that way, then so be it. We can't all agree on everything all the time. Someone will have to fix the mess at some point. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
RE: Icon / mime association..
On Mon, 2006-10-16 at 19:46 +0300, Kustaa Nyholm wrote: My extensions (*.jdwg) are now correctly associated by installer with my mime types (application/vnd.jdwg) and my jDraft.desktop shows the icon I specified for my application and my documents also show the icon I want. The application launches from .desktop file or the documents. Everything is great, well almost... ..the actual application executable (which is a shell script with embedded executable jar file) only shows the standard (I presume) icon for shell scripts. A shell script is still a shell script. Shell scripts do not support resource embedding as win32 binaries do. You can't change the icon to some specific icon only for that script, automatically. You can set it as a user in nautilus by setting a custom icon for the file, though. There is some work being done, however, to allow icon resources in win32 binaries to be used as the icons for those programs in nautilus, for things that will work under WINE or similar. Linux ELF does not have native resource embedding, and there is currently no standard method for doing such embedding in the binary. As an example, open /usr/bin in your file manager, and notice how every single app has the same icon for exectuable applications. You'll have to live with this for the time being. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon / mime association..
On Thu, 2006-10-12 at 17:24 +0200, Magnus Bergman wrote:
On Wed, 11 Oct 2006 21:25:22 +0300
Kustaa Nyholm [EMAIL PROTECTED] wrote:
Magnus Bergman wrote:
The icon for a mimetype is expected to be in
DATADIR/icons/THEME/*/mimetypes. In other words, the icon used
depends on the current theme [3].
First of all, thank you for taking the trouble to explain.
I'm almost there but after experimenting with Ubuntu for an hour now
I still do not get it to work for me.
Gnome shows the mime type correctly for my document files and when I
double click them the application launches correctly. And I've even
got a nice icon for my application showing up in the 'applications'
folder.
But I can't figure out the correct name / place for the icon for mime
types.
I think it should be in
/usr/share/icons/hicolor/48x48/mimetypes
Yes, that is correct. If you use autoconf it is a good idea to
place it get the datadir from there instead of assuming it to
be /usr/share.
This is actually a bad idea. If another application handles the type,
and wants to provide a custom icon for the mime type, and tries to
install it in the same place, we have a file conflict. See the related
mails from Alex L. to this same list, for a proposed solution, where the
MIME type XML file specifies a list of fallback icons to fall back
through.
but what is the correct file name given my mime type
'application/vnd.jdwg' ?
The spec implicitly says that the slashes and hyphens should be
replaced by underscores. It doesn't seem to say anything about the dot
thou. Looking at the Gnome icon theme you can see it has hyphens
instead of underscores in the filenames so that seems to work too. But
according to the spec I'd say I should be:
Which spec says this? I was to understand that the MIME spec had been
changed to match the Icon Naming spec, as previously the MIME spec had
been suggesting what RoX did, which was different from both GNOME and
KDE on a large level.
application_vnd.jdwg.png
Actually, it should be application-vnd.jdwg.{png,svg} in this case.
-- dobey
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Ideas concerning desktop application icons
On Mon, 2006-08-28 at 14:45 +1000, Andy Fitzsimon wrote: There's no information at http://ixons.info/ whatsoever. Right. I looked at the web site, and it seems like there is absolutely no content about what the goals are here. It mentions an IRC channel on freenode (#ixons) which I also joined, and seem to be the only person in. I am still idling there. What are the goals of this project exactly? How do they differ from the goals of the Icon Theme Specification and Icon Naming Specification? How can the goals be better intertwined with these existing projects? Answers to these questions would be very helpful in telling people what it is exactly you plan to do here. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
RE: Multiple DeskTops, HiColor theme, standardized icon names,menu icons
On Fri, 2006-06-30 at 12:41 -0700, Bastian, Waldo wrote: I don't have a real opinion on that, you may be able to just add an $appname subdir to the existing icon-spec directory hierarchy. You mean something like $XDG_DATA_DIRS/icons/$appname? I don't think that's appropriate, as it would imply that $appname was a theme, which it isn't. Apps shouldn't be installing their own new themes. Well.. since you shoot your own suggestion down already, try again :-) Please enlighten me as to when, how, and why you think so. I suggest $XDG_DATA_DIRS/icons/theme/size/context/$appname/ You think the proposal James and I agreed upon is bad, but you want applications to randomly install icons into other themes? Please tell me this is some sick joke. That is a totally appalling idea. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Multiple DeskTops, HiColor theme, standardized icon names, menu icons
On Thu, 2006-06-29 at 11:44 -0600, Aaron J. Seigo wrote: On Thursday 29 June 2006 09:09, you wrote: On Thu, 2006-06-29 at 01:47 -0600, Aaron J. Seigo wrote: On Thursday 29 June 2006 01:22, Bastian, Waldo wrote: icons into a $XDG_DATA_DIRS location. It's ok to add these locations to the search path ... aside from the performance penalty of having yet more paths to look at? we already look at a rather large number of directories in the icon spec, no? There would in fact, be exactly 0 performance penalty in KDE, given that it already implements the proposed change in a KDE-specific manner. i assumed this was in addition to, not instead of. Given that all possible directories aren't going to exist, you are still going to end up with no more additional directories causing hits to the disk, than you have now. Or shouldn't anyway. I don't know the code. It could be badly written, and hit the disk for every possible directory during every icon lookup. But that's a bug anyway and should be fixed. Even if we do as you suggested in another mail, and put the icons in $datadir/appdata/$appname/icons... you still end up with the same need for fallback in KDE. So using that as an argument against just putting the icons in $datadir/$appname/icons... doesn't really work. The search-list for app-specific icons should include $XDG_DATA_DIRS/$appname/icons/$theme/... in addition to the other is $XDG_DATA_DIRS/$appname already in another spec, or does this introduce a new namespacing mechanism? if so, i'd suggest that having a whole ton of dirs, one per app, in $XDG_DATA_DIRS/ drowns out the other non-app dirs such as Trash, mimetype and applications. and heaven forbid anyone actually make an app called Trash, mimetype, applications or any of the other special dirs in there ;) These directories are not globally special, and outside the scope of freedesktop.org, would already create a conflict if someone wanted to write an application called Trash, mime, or applications anyway. Just the same as if someone wanted to write an app called apps. no conflict would occur if they were inside a subdir specifically set aside for application directories. there is method to our madness. This still needs to be in a spec somewhere, no matter what directory these icons end up in. Currently, the specification implies that *all* icons that an application wishes to be themeable, should be installed to hicolor. This is very bad, and also not the actual intention of the spec. The intention of the consensus that James and I reached to put these icons in $datadir/$appname/icons as a method for applications to provide their own fallback icons without any extra programatic work for the app developers, was to resolve this confusion, and add to the spec where it so direly needs addition. conflict is already present. Granted, mime and applications should probably be in /var anyway, given that they are registry databases, and are not specific to a single application. And putting a directory called Trash in /usr/share/ just seems bad to me to begin with. ah .. i think we're perhaps talking about slightly different things, and my use of the env vars literally probably didn't help the confusion. sorry. you are focussing on the system-wide directories, while i'm pondering not only that but also the additional impacts to ~/.local and ~/.config which reflect the same structure and are used for single-user modifications and installations. they are the user's XDG_DATA and XDG_CONFIG dir, so to speak. We're probably certainly talking about different things. Given that you already pointed out that kde stores data in ~/.kde/something, this new argument about .local and .config is irrelevant. The Icon Theme specification clearly defines ~/.icons as the home search path. This new proposal in no way affects that, nor does it need to alter the behavior for ~/.kde which is outside the scope of the specification anyway. i do think that putting application dirs in the same dir as non-application dirs (as we do in /usr/share) is utter insanity; i'm not the only one and that is why KDE doesn't do that. it would be nice if we didn't let this disease spread into user's home directories as well. it would be -awesome- if we could fix it in $XDG_DATA_DIRS as well, and the fix is pretty trivial: move desktop app data dirs into a directory specifically set aside for app data ... or move everything else that isn't app-specific data somewhere else, though that probably makes less sense. but one or the other. I don't disagree that non-application dirs that are not part of the FHS specification, don't belong in /usr/share. User's home directories are not at issue here. The change to ~/.kde to match the change to the system directory changes would be minor, and as it sounds, falling back to the old stuff would be inherent in the code anyway. What you
RE: Multiple DeskTops, HiColor theme, standardized icon names, menu icons
On Fri, 2006-06-30 at 07:59 -0700, Bastian, Waldo wrote: This probably doesn't make much difference (at least for now) for KDE apps and GNOME apps because they will continue to use their respective icon loaders to load the icons. But, what about third party apps? There needs to be standard so that they can have the DeskTop (probably through Portland) load the themed icons. Third party apps need ONE standard to follow for menus, icons, MIME types, widget themes, color schemes, etc. It is undesirable to impose requirements on third party apps wrt where they should install application private icons. It's ok to have standard locations where themed versions of such icons can be provided by other parties (fourth parties?) and to ask applications to take these locations into account when looking up icons if theming of said icons is supposed to be possible (which may not always be the case). So as a third party developer, I should NOT install my app icon to hicolor, or my MIME type XML description file to $datadir/mime/packages, or my .desktop file to $datadir/applications? We're already imposing requirements on third party apps wrt where they should install things. Why should enabling the ability for a standard method of fallback for icons that those apps want to have themed, be any less appropriate? Every time a developer asks me where the hell they are supposed to put icons that may conflict with other applications, that they want to have themeable, and want to fall back to in the event that themes don't provide these icons, I'll gladly refer them to you. And you can explain how we're half-assedly writing specifications that are confusing, and aren't actually useful for anything beyond the theming of a single icon. Because I'm quite tired of doing it myself. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
RE: Multiple DeskTops, HiColor theme, standardized icon names, menu icons
On Fri, 2006-06-30 at 08:18 -0700, Bastian, Waldo wrote: http://portland.freedesktop.org/wiki/ Portland is a new Free Desktop initiative coming out of the OSDL Desktop Architects' Meeting (hosted in Portland, Oregon in December 2005). Portland intends to generate a common set of Linux Desktop Interfaces and Tools to allow all applications to easily integrate with the free desktop configuration an end user has chosen to work with. Did I miss something? If an app is going to request an icon through the Portland interface library, aren't they going to need to be installed in a standardized location as well. Not per se. If Portland can't find a themed version of the icon, the app can use any other method it seems fit to get to an icon. And as I mentioned already before (Did you see that mail? It's hard to tell from your other mails) it is undesirable for applications to install icons into $XDG_DATA_DIRS if there is no actual requirement for doing so. Please point me to where in the spec that it says applications should not be installing icons into $XDG_DATA_DIRS. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Multiple DeskTops, HiColor theme, standardized icon names, menu icons
On Thu, 2006-06-29 at 00:00 -0600, Aaron J. Seigo wrote: I don't see KDE needing to do a bunch of work erm. i do. and i'm going to guess i'm a bit more familiar with the code base? Well, my patch to implement this feature in GTK+ is a grand total of 4 lines of changes. The first of those is a single character change. The next line is a new blank line, and the next 2 are the actual code. Given that KDE basically already implements the feature, but simply does so with a different sub-directory, I can't possibly see how it could be a bunch of work for KDE. Also, please stop using the bunch of work cop-out to fixing problems. Whether it's done now or later, it's going to have to be fixed across all desktops. If you think it's a bunch of work now, imagine how much work it's going to be when a lot of related things change down the line, and it's still a problem. Saying it's a bunch of work and therefore we don't want to do it, is functionally equivalent to saying we don't care. You might as well just say we don't care to solve this problem. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Multiple DeskTops, HiColor theme, standardized icon names, menu icons
On Thu, 2006-06-29 at 16:30 +0200, Stephan Kulow wrote: Am Donnerstag, 29. Juni 2006 16:23 schrieb Rodney Dawes: On Thu, 2006-06-29 at 06:56 +0200, Stephan Kulow wrote: Am Donnerstag, 29. Juni 2006 00:54 schrieb James Richard Tyrer: This probably doesn't make much difference (at least for now) for KDE apps and GNOME apps because they will continue to use their respective icon loaders to load the icons. But, what about third party apps? There needs to be standard so that they can have the DeskTop (probably through Portland) load the themed icons. Third party apps need ONE standard to follow for menus, icons, MIME types, widget themes, color schemes, etc. Why do they need to have it standarized where to put there data beside what the FHS or LSB say? I don't know. Given that they aren't currently where the FHS says they should be really, I'm not sure what you're asking. The proposal here is to put things where the FHS says they should be. Maybe I was unclear: I'm asking why we would spec anything not said by FHS. But $XDG_DATA_DIRS/applications, $XDG_CONFIG_DIRS/menus, etc... aren't in the FHS. The purpose here isn't to spec something that isn't said by the FHS. It's to extend upon what the FHS already says, and provide a sane way for applications to install themable private icons. So, I'm still a bit confused as to why this questions is even being asked. The application will use icon loader FOO and they need to put their icons where FOO expects it. That can be _anywhere_ and I can't see any technical reason why the icon loader should be interchangable for one app. But who specifies where FOO expects it? I don't see any particular The FOO iconloader documentation. If portland wants to provide a toolkit agnostic iconloader, then portland documentation has to specify where to put the icons. If the app is a GTK app, then GTK documentation needs to specify it. If it's a motif app, then ... hmm, I guess you're on your own then. Then why do we have a specification that says where to put icons at all? Why isn't this all just part of the loader documentation? -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Multiple DeskTops, HiColor theme, standardized icon names, menu icons
On Thu, 2006-06-29 at 01:47 -0600, Aaron J. Seigo wrote: On Thursday 29 June 2006 01:22, Bastian, Waldo wrote: icons into a $XDG_DATA_DIRS location. It's ok to add these locations to the search path ... aside from the performance penalty of having yet more paths to look at? we already look at a rather large number of directories in the icon spec, no? There would in fact, be exactly 0 performance penalty in KDE, given that it already implements the proposed change in a KDE-specific manner. The search-list for app-specific icons should include $XDG_DATA_DIRS/$appname/icons/$theme/... in addition to the other is $XDG_DATA_DIRS/$appname already in another spec, or does this introduce a new namespacing mechanism? if so, i'd suggest that having a whole ton of dirs, one per app, in $XDG_DATA_DIRS/ drowns out the other non-app dirs such as Trash, mimetype and applications. and heaven forbid anyone actually make an app called Trash, mimetype, applications or any of the other special dirs in there ;) These directories are not globally special, and outside the scope of freedesktop.org, would already create a conflict if someone wanted to write an application called Trash, mime, or applications anyway. Just the same as if someone wanted to write an app called apps. If any of these needed to store private application data, the likelihood of a conflict is already present. Granted, mime and applications should probably be in /var anyway, given that they are registry databases, and are not specific to a single application. And putting a directory called Trash in /usr/share/ just seems bad to me to begin with. i'd really suggest having $XDG_DATA_DIRS/something/$appname instead for this reason. i lean towards appdata myself (and wish that applications/ had been named something else, but only so many tears can be shed for the past ;) I don't see how the repetition of a sub-dir to contain the data that should clearly be stored at the level of proposed sub-dir, as per the FHS, actually solves anything. You still have a very large number of directories below that. Also, this thread is about themable private icons only, and has no bearing on other private application data. However, I do believe other such data should be installed in accordance with the FHS as appropriate. That said, I would like to see an icon-spec that conforms with existing implementations and that can be referred to by LSB 3.2 (ideally icon spec 1.0) before new things get added that existing implementations do not yet support. agreed. do you have a list of outstanding items you'd recommend / like to see for a 1.0? This thread, and the other mails from Pascal de Vuyst and Oswald Buddenhagen point out several confusing issues surrounding the Icon Theme specification. I also don't think we should be calling it 1.0 yet, especially without dependence on the Icon Naming spec, and it also being at 1.0. There are way too many issues surrounding icon themes to just be blindly calling the specs 1.0 and shoving them into the lsb. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Multiple DeskTops, HiColor theme, standardized icon names, menu icons
On Thu, 2006-06-29 at 17:09 +0200, Stephan Kulow wrote: Am Donnerstag, 29. Juni 2006 16:42 schrieb Rodney Dawes: Then why do we have a specification that says where to put icons at all? Why isn't this all just part of the loader documentation? Because we expect all desktops to show menus and mimetype icons and for those the provided icons have to be in places where _everyone_ looks. I would call them public icons. For private icons there is no such need IMO. You (like everyone else seems to be doing) are confusing the term private, with static. For static icons in an app, of course there is no need. Those icons are static and part of the application's data section in the binary, or in a private directory with hardcoded paths. But for an application that wishes to have themable icons, this is not feasible. If one is to run Evolution under KDE for example, do you expect Evolution to not have any of its icons available? Wouldn't you want the icons to perhaps be in the same style as the icon theme you're using at the time, when you run it? -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Multiple DeskTops, HiColor theme, standardized icon names, menu icons
On Thu, 2006-06-29 at 17:39 +0200, Stephan Kulow wrote: Am Donnerstag, 29. Juni 2006 17:16 schrieb Rodney Dawes: On Thu, 2006-06-29 at 17:09 +0200, Stephan Kulow wrote: Am Donnerstag, 29. Juni 2006 16:42 schrieb Rodney Dawes: Then why do we have a specification that says where to put icons at all? Why isn't this all just part of the loader documentation? Because we expect all desktops to show menus and mimetype icons and for those the provided icons have to be in places where _everyone_ looks. I would call them public icons. For private icons there is no such need IMO. You (like everyone else seems to be doing) are confusing the term private, with static. For static icons in an app, of course there is no need. Those icons are static and part of the application's data section in the binary, or in a private directory with hardcoded paths. But for an application that wishes to have themable icons, this is not feasible. If one is to run Evolution under KDE for example, do you expect Evolution to not have any of its icons available? Wouldn't you want the icons to perhaps be in the same style as the icon theme you're using at the time, when you run it? So your interest to make it possible for icon theme authors to provide themed evolution icons? That would make sense to me, but that wasn't said yet. Because KDE in itself doesn't care what evolution does with its icons. No. My interest is to make it possibly to sanely theme app-specific icons for any application. And yes, I /have/ stated this several times. But it seems nobody wants to actually read that bit of the thread. They want to just jump into the middle of the thread and claim it can't be done because it'll need KDE developers to actually do a little tiny bit of work, or that all the discussion is totally moot. generalized_rant And, quite frankly, I'm tired of it. If you have actually read the entire thread, and are confused about some bit of it, then you should be asking questions about those bits, not jumping in and claiming everything discussed is all wrong and/or moot. It's disrespectful, and doesn't add anything to the discussion. It's just a waste. If that's all anyone else has to say in this thread, that the entire discussion is pointless/moot or that it's not doable because they don't want to make a line or two of changes to code to make it work, then I respectfully suggest those people not even bother posting, and just go on about their business. It's upsetting the thread, and it's a waste of everyone's time. /generalized_rant Thanks. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
RE: libxdg-vfs - screenshots
On Wed, 2006-06-28 at 10:08 -0700, Bastian, Waldo wrote: Sure, that's a problem, but you have that problem nowadays as well. Look at the usability of the system as a whole and you will find that it is horrible as long as you have different themes and button order settings between Gtk and Qt applications. It's hard to say whether an application with a file-dialog that doesn't match the widget of the rest of the app is worse than an application with a file-dialog that doesn't match the other file-dialogs on the system. I'm inclined to think that a user adapts easier to an out-of-place file dialog if there is only one kind of file dialog he has to deal with. But let's not go there. Yes, fix the look feel, but while we wait for that to happen, let's not use it as a stop-energy excuse for not looking into solutions for other issues. Stop-energy excuse? I think not. This is a public mailing list, meant for multiple to express their views on the matters presented therein. My point of view with the suggestion at hand, is that it will detract from the usability of the application. And as was already brought up, it isn't technically feasible to do at this point anyway, as many apps insert custom widgets into the dialogs. The usability issue is not so simple as to be minimized to the button order of the resulting changed dialog. If it were, then I would be all for doing the dialog switching. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
RE: Multiple DeskTops, HiColor theme, standardized icon names, menu icons
On Wed, 2006-06-28 at 10:59 -0700, Bastian, Waldo wrote: I don't know why KDE chose: apps for the subdirectory when: kde would have been a better choice. KDE's file hierarchy is explained here: http://www.kde.org/areas/sysadmin/fsh.php The information here doesn't explain *why* the directory name apps was chosen, and *why* it was made a sub-directory, rather than following the specification in the FHS. It merely explains what the different directories are meant to contain. Are you opposed to moving the stuff in share/apps to the share/ directory directly? Or were you just pointing out the page that contains some information about the KDE directory layout? Just wondering, as I am about to write up a patch to the Icon Theme Specification based on the consensus that James and I came to about app-specific icons being in there. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Multiple DeskTops, HiColor theme, standardized icon names, menu icons
On Wed, 2006-06-28 at 22:18 +0200, Thiago Macieira wrote: Thiago Macieira wrote: Are you opposed to moving the stuff in share/apps to the share/ directory directly? Or were you just pointing out the page that contains some information about the KDE directory layout? Just wondering, as I am about to write up a patch to the Icon Theme Specification based on the consensus that James and I came to about app-specific icons being in there. This is completely off-topic for this mailing list. We're talking about application-specific data files. Wherever they choose to install them and however they're laid out is not a cross-desktop issue. If you want to discuss that, the mailing list is [EMAIL PROTECTED] Hold on, I completely missed part of your reply. I must have also missed a greater part of the discussion, but did you guys agree about standardising application-specific data? James and I agreed that app-specific icons should be installed to the $XDG_DATA_DIRS/$appname/icons/$theme/... path structure, and that these such paths should be added automatically to the search list by the icon theme implementation. I already have a working patch that adds this to the GTK+ icon theme implementation. I just need to write a patch to the spec to include this, and get it in, along with getting the GTK+ patch in, and KDE needs a patch to look there and fall back to apps/... for backward compat. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Multiple DeskTops, HiColor theme, standardized icon names, menu icons
On Thu, 2006-06-29 at 00:26 +0200, Kenneth Wimer wrote: If they are privately themed icons (your words) why should it matter where they put them? They are privately installed themable icons. If they are private, and it doesn't matter, then they aren't themed. Perhaps they are private for a reason? They are installed to a private location, because applications installing icons to hicolor, which other applications may also use, and thus conflict with, is very bad. This is quite blatently described in the full content of the thread. I'd suggest reading it. It's a good read for the most part. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Multiple DeskTops, HiColor theme, standardized icon names, menu icons
On Thu, 2006-06-29 at 00:49 +0200, Thiago Macieira wrote: Sorry, I completely disagree. Why should application A care about application B's private files? They are *private* so they can: a) disappear from one version to the next b) change names c) be in a completely different format Nobody said that application A would care about application B's private data, or even implied that it would. What application A does care about, is that it doesn't conflict with application B's data, by installing a file of the same name into the same location (hicolor). These icons need to be themable, the same as the rest of the icons in an application. What I do agree is that an application should be reserved one directory where it can store any kind of file it wants, in whatever layout it wants. The FHS already describes two possibilities already: /opt/$appname /usr/share/$appname I think the second option is inefficient if we take into account the number of applications that get installed. We confuse /usr/share/$concept with /usr/share/$appname. They are no more confused they they are now. You can't possibly tell me that share/apps and share/applications isn't confusing. It is the very definition of the word. PS: like Waldo said, KDE was meant to be installed in /opt/kde, so /opt/kde/share does not follow FHS and should not appear at /usr/share. While KDE may not have been meant to be installed into /usr 8 years ago, the option to do so, should not be disallowed. KDE is a lot of things it wasn't meant to be, 8 years ago. KDE needs to become a fully integrated piece of the desktop. We shouldn't be treating it specially because of what someone wanted some piece of it to be like, 8 years ago. It should be a part of the creation of specifications for all desktop environments, and an example of implementation to them, as well. -- dobey ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Multiple DeskTops, HiColor theme, standardized icon names, menu icons
On Fri, 2006-06-23 at 23:44 -0700, James Richard Tyrer wrote: and to standardize this they would go in: $XDG_DATA_DIR/apps/app_name/icons/theme/size/type If this is not part of the standard, SMcC's posting illustrates that GNOME does not have a standard way to deal with this and pointed out that KDE does. I suggest that the KDE method (which works --except for bugs) be added to the standard if RD can live with it. GNOME is not the only thing that doesn't have automagical lookup of app-specific icons in a private directory that mimics the layout of icon themes. GNOME simply implements the Icon Theme Specification, which clearly does not state any way to do this. KDE implements things which are above and beyond the specification, as well as things which make the transition to standardized names, so that we can actually share themes across the desktops, quite difficult. Any other piece of software which implements the specification, and doesn't add additional hackery to make it do special things, as KDE does, is going to have the same problems. So, with that, can we please try to avoid simply limiting the details to those that GNOME and KDE conflict on? This is supposed to be about the independence of desktop implementations, not simply the peaceful co-existence of the two major ones. That said, $datadir/apps is not part of the FHS, and seems redundant to me, as well as adding implied conflict with $datadir/applications, which is part of an XDG spec already, as apps is mearly the short version of applications. In fact, according to the FHS, it looks like the app's static arch-indep files should be in $datadir/app_name, unless there is a more specific sub-directory where data should be placed, such as in $datadir/games/app_name. The redundancy of the apps directory, and implied conflict with applications directory, along with the fact that the FHS doesn't specify app-specific data being in apps/app_name are my main concerns with your proposal. But, I have no issue with a similar solution which doesn't conflict with other specifications, being included in the Icon Theme Specification, along with very clear text about how applications should install these icons. -- dobey PS: I already have a patch to GTK+ which basically adds this feature to the icon theme implementation there. I just need to also patch a few apps to install icons accordingly to test with, to make sure it all works right. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
