Re: gnome-panel ideas: combined launcher/taskbar/system tray
n-like graphic without creating a GTK button?). Another thing I thought of was tabs containing borderless buttons within, for the different groups in the application list, but the problem with those is that people do not really expect tabs be like that. The most natural is to have 3 buttons (with varying styles), but that way has looked quite ugly every way I have tried it. I guess this is really just decoration, so how does one create decorations that follow the current theme? There, that's my rambling on the topic. Bye, -Dylan McCall PS: I'm Mr. Picklesworth in that forum. On 10/11/07, Jared Moore <[EMAIL PROTECTED]> wrote: > > > Hi guys, > > I'd like to point out this spiffy idea: > > Concept demo: > http://users.tpg.com.au/adsltimu/task-system-launcher.html > > Discussion: > http://ubuntuforums.org/showthread.php?t=320315 > > Jared > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: User's preferred search tool
ragging an image from F-Spot to send it as an attachment in Evolution. Smooth!), MIME types as well as a consistent user interface toolkit. These don't quite cut it, though, since it still often involves more work than the user feels like doing. I find that drag and drop and finding files via the file manager work in different directions, and one always tends to be more suited to a particular task. File management is a bit jealous of drag and drop, though, since the latter feels far more clever, and does way more work for the user! That is where desktop search comes in. With desktop search, done (the way I think is) right, the positives are two-fold: Desktop search helps people to have data consistently available to multiple programs under a single interface (without having to hunt for the files manually), but that power only comes through if it is attached to each program. Otherwise, as with the current situation, this is still just an extension of the file manager's functionality. Having it in the file chooser widget via Search is a great start, but it's still not enough. (Search folders in the Places list are another good step, as we see in MacOS out of the box, and in GNOME with a bit of setup). I think the real leap forward comes when apps can safely use desktop search for everything, from seeking through their own databases (thus having a single way of doing search queries across the desktop, instead of each program having its own little search engine. Wouldn't it be great if Beagle's Boolean searching happened everywhere, rather than just in Beagle's main front-end? I always expect that, but I know it isn't happening yet). That coolness could go all the way back to a photo manager doing something awesome: Quickly locating new image files larger than 1024x768 pixels, perhaps with digital camera meta data, and offering to import them. That leap is only possible when we have a single desktop search system, endlessly extensible by interchangeable search engines. We all want it, and the search engine people would all love having that kind of use available for their tools. The applications like photo managers, even more so. It may take a while for everything to be implemented, but I think we are all in the same boat here. It is in everyone's best interest to standardize this. All we need now is a standard. Bye, -Dylan McCall PS: Speaking of abstraction, sorry if my small amount of text formatting comes out weird on your end. On 11/1/07, Luca Ferretti <[EMAIL PROTECTED]> wrote: > > > Il giorno mer, 31/10/2007 alle 12.57 -0400, Matthias Clasen ha scritto: > > On 10/30/07, Luca Ferretti <[EMAIL PROTECTED]> wrote: > > > > > > > Stuffing more and more things into the preferred applications capplet is > really > > not the way forward. I'll end up like gnome-volume-manager if we > > continue this... > > > > Really, we need a single search tool that can talk to various engines. > > Matthias, this is not the issue I was trying to settle. > > Of course the GNOME Desktop needs a new default search tool, that > ideally should talk with the user's preferred engine or the one > available on system (and I hope it will be the best available tool to > search in my data), but I don't think we should lock out any other > alternative. > > What if I like Google Search? It's an available solution for Linux/GNOME > desktops, but I don't think we'll never include it as backend for this > future tool. > What if I will dislike that tool and I'll want to use another? Maybe the > new tool will obsolete all others? > OK, I will always able launch my preferred tool from its menu entry > under Application menu, but I'll not able to quickly hit the "Search" > button on my keyboard or choose Places->Search. It's just like the > gnome-main-menu applet that shows the search entry only if you have > beagle (at least the last time I tried)... > > And about the growing size of Preferred Application capplet, yes, it's > true, but could be physiological if we like to provide a reasonable > degree of choices to users (by now only 6 applications). It's the only > available place to setup default applications that don't open files. > Maybe we should change the UI using a list on the left, as suggested by > HIG if you have a lot of stuff[1], to choose the section (web browser, > email client...). This could allow to merge this capplet with > gnome-volume-manager[2]>, something like > http://www.rubicode.com/Software/RCDefaultApp/ but of course with less > steroids. > > But this could mean that currently the capplet UI is not well scalable, > not that this is a reason to give up an useful (IMHO) feature. > > So, IMHO, "the capplet is a mes
Re: Rise of the Plugins
I think bumping functionality to plugins is a pointless operation,
especially in a desktop environment that tries to follow the idea of having
a lot of small programs that each do simple tasks very well. Interfaces like
D-Bus let us create top-level applications (for lack of a better term in my
dictionary) act like plugins by communicating all sorts of information with
applications in an intuitive, generic way. The coolest thing with that sort
of functionality is that there is a lot of room for standardization, such
that programs can interoperate via D-Bus with other programs that they were
not even intended to work with.
This plugins madness, on the other hand, involves every program having its
own silly way of doing plugins. In addition, like joined windows handled by
individual programs themselves to represent multiiple documents (a ramble I
will leave for another day; bottom line: Fluxbox does it right), the extra
processes are effectively concealed from lower level systems. I can't say I
am hugely knowledgeable about the "lower level systems" that I vaguely
mention for fear of sounding like too much of an oaf, but I know there are
already systems that handle resource distribution and memory management for
processes they know how to handle. These plugin systems tend to do that same
thing in their own ways, but those ways happen to be much less carefully
crafter and do not have years of attention behind them.
Besides that, those plugin systems rarely offer functionality we cannot get
through even a separate program. One unusual example is Epiphany's
extensions. Those tend to be very simple plugins that trigger single
additions to the core behaviour of the program. Going through the dialog
where they are chosen, it feels a lot like regular program preferences, and
that is made moreso by the unusual ability for extensions to immediately
start working without the need for a browser restart. For example, I can
turn on the Tab Sizer extension and have my tab bar immediately sized to
always fit on the screen with no need for scrolling.
In theory, Evolution's plugins would offer that same feel, but they don't
really. I think a reason for that is they often add /a lot/ of functionality
and require configuration; one must peel through two layers of configuration
tools to get what he needs. Instead of Epiphany ("Resize tabs to fit
window?" "Block ads?" "Scroll with middle mouse?"), Evolution's plugins are
a lot of groups of yet more options ("IMAP Features") -- although this isn't
always the case, for example with "Block plain text".
Frankly, I think the underlying flaw is in Evolution's core design. It is
built to be a very big program, promoting very big plugins; if each plugin
there just did a single thing each, we would have not just tens, but
hundreds of them!
Clearly, the problem of having an enormous core was observed and acted upon,
but the solution just creates a new problem: A lot of plugins, which feels
frighteningly similar to KDE. A smoother course of action, and one which
fits more with the expected behaviour of GNOME software, would have been
(and still would be) to split Evolution into a bunch of individual programs.
Not just sub-programs handled by a miniature operating system, but actual
individual tools; Mail, Calendar, Notes, etc.
This way they are modular components in a way that other applications can
easily work with, and, most importantly, those preferences dialogs shrink to
a tiny fraction of their initial size. No need to split Mail, Calendars,
etc. via tabs; the options can be easily divided and quickly figured out by
the easy idea that these are different programs, with different top-level
windows. In the places where plugins do still serve their purpose, they can
be much simpler plugins built for each component. Plugins could be nicely
aimed at certain components, so instead of being for Evolution as a whole,
being for Evolution's mail handling system.
Most importantly, when functionality so significantly unusual that it
couldn't fit in the core of Evolution still wants to work within Evolution's
systems, it would not have to be implemented as a huge plugin, but as a
simple alternative to one of its major components, easily implemented by
adhering to some standards so that it "looks" the same as the old component
(to Evolution's different programs), and otherwise being a completely normal
application visible in the main menu.
Bye,
-Dylan McCall
On Nov 14, 2007 12:50 PM, Baptiste Mille-Mathias <
[EMAIL PROTECTED]> wrote:
> On May 17, 2007 5:26 PM, Vincent Untz <[EMAIL PROTECTED]> wrote:
>
> > Moving features to plugins/extensions
> > =
> > (thanks to Baptiste for having raised this specific issue)
> >
> > One of the first thing people are doing with plugins/extensions i
Re: Evolution Plugins (Was Re: Rise of the Plugins)
That is interesting to know a bit better how Evolution is organized. Thanks
Sankar.
Still, that makes it seem like a whole lot of unnecessary engineering. We
already *have* a shell: The GNOME desktop.
A bit off topic, but the miniature shell idea makes Evolution very confusing
to use. Program menus should not really change, but Evolution's are actually
completely different depending on what component is being used. To make
matters more confounding, many menu items change their position between
components.
On the topic of Rhythmbox, I do not have too many problems with its plugins
list (or at least the type of plugins it attracts). They tend to offer small
additions that could indeed be represented by single check boxes in the
program's Preferences. It would be good to see those moving straight into
the Preferences dialog, though, and the idea of them being plugins
abstracted to avoid the confusion of that term (though still present under
the hood). That they are plugins and not built in to the program's core
should be of no importance to the end user. Granted, there would have to be
a user interface miracle to fit that type of extensible interface in without
looking and feeling horrendous, but I'm hopeful. It could be an interesting
experiment!
Even just being an extra tab in Preferences (instead of a new dialog as it
is now) could do the job fine.
Bye,
-Dylan McCall
On Nov 17, 2007 7:26 AM, Bastien Nocera <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-11-16 at 11:38 +0100, Vincent Untz wrote:
>
> > Maybe 95% of the plugins of evo should not be displayed as plugins. They
> > should either be preferences in the standard preferences dialog, or they
> > should be enabled anyway.
>
> Totem and Rhythmbox have a number of "hidden" plugins that take care of
> core functionality, and are never shown in the UI, but allow splitting
> at the code level.
>
> > This is not only true for evo, rhythmbox has the same issue (although
> > there are less plugins there)
>
> Most of Rhythmbox' plugins should be preferences indeed, and it would be
> pretty trivial to have them be so. For example, the iPod, MTP removable
> media plugins, and the store plugins (Jamendo, and Magnatune) could be
> activated/disabled via a source selection that would allow you to
> disable some sources ("[ ] Show Play for Sure device in the sources").
>
> http://bugzilla.gnome.org/show_bug.cgi?id=484435
>
> The cover art display in Rhythmbox could be a "show cover art" tickbox
> instead as well.
>
> http://bugzilla.gnome.org/show_bug.cgi?id=497665
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: enable accessibility by default for GNOME
> Hi All: > > I recently had a nice discussion with the release team about the > viability of enabling accessibility (i.e., the AT-SPI infrastructure) by > default for GNOME. As a result of that discussion, I'm approaching the > broader GNOME community with a proposal to do this. :-) > > Accessibility has currently enabled by default for development builds > since 2.17 (http://bugzilla.gnome.org/show_bug.cgi?id=362457), so there > has hopefully been a fair amount of testing-in-the-large with it > already. We also recently got rid of one of the last obviously nasty > things it was doing -- gnome-session no longer pops up that annoying > "the at-spi infrastructure didn't start" window. Even in the event that this proposal does not happen, I think GNOME's arrangement for enabling accessibility lacks courtesy at the moment. For example, try (without a11y turned on) to open Mouse Preferences and enable one of the mouse accessiblity features. Boom! Horrible error message: "Mousetweaks requires Assistive Technologies." I used this as the first example in a little post I made regarding courteous software. Let's pretend for a moment I am a disabled person who has trouble with mouse buttons. I am trying to turn on a critical accessibility feature, and I think I see light at the end of the tunnel. ... Nope, never mind. Instead, this program decides to tease me! It throws a cryptic error message, telling me that it requires "assistive technologies". It essentially orders me to give it these technologies, and it refuses to do anything until I satisfy its demands. I can feel the confused phone calls starting already! In the layman's thoughts: Of course it "needs assistive technologies"; it /is/ an assistive technology! This error message is lazy, cruel and unusual. It does not offer to enable assistive technologies, and it does not elaborate on what the heck it means to begin with. It simply refuses to work, leaving people to give up or phone their relatives. There is no reason for this evil, either; the software here has complete access to the necessary controls such that it should be able to transparently enable "Assistive Technologies" without the end user needing to think about it. At the least, it could have a button leading to the "Assistive Technologies" preferences or a kind explanation of what "assistive tecnologies" are if not the technology the user is trying to enable. Of course, GNOME normally does better than this. This project is characterized for never having unnecessary popups, always presenting the user with answers instead of pounding him with problems. Polishing loose ends like that one could solve a lot of accessibility problems magically. As for enabling accessibility by default, my personal thought is that distribution installers should offer that option in there, perhaps just "install in accessibility mode" at the boot menu for the live CD ones. If someone desperately needs assistive technologies, he is still going to have trouble enabling the components all himself after already struggling through an installer. The distributors should have mercy early on. Perhaps there is something GNOME can do to encourage such practise. Come to think of it... if you'll excuse the ignorance here, can't we just have another session choice alongside the regular GNOME one in GDM for Accessible GNOME, or is there something extra extra magical happening? Whichever way, the user should not have to think "enable Assistive Technologies" before doing anything, and I too would love to see a movement towards that. I have always thought it central to GNOME to avoid hounding the user with unnecessary choices. Therefore, he should find the particular assistive technology he wants and enable that without needing to think about the underlying systems. I don't think logging out and logging in is a big issue, particularly when first setting up. Besides, doesn't session saving work here? ...Maybe, with that in mind, there could be a magic "refresh this session" button that saves the session, logs out and logs back in really quickly, but that is way off topic. Bye, -Dylan McCall signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME-panel, more precisely GNOME-clock issues
> If a town (usually a town with an airport) is missing, file a bug > against libgweather. I think the current giant menu is broken and not at all scalable. It could do with being addressed with that specifically in mind. Perhaps we should have a universal location picker widget for this and other timezone selections. Why not just have the user click a point on the map then type the name of the location he has chosen? It could be filled automatically, in some instances, and then perhaps latitude & longitude snapped to the real location when user input matches the app's own dictionary of locations, but done very quietly! This way, the user gets full control but the application can still be helpful without pretending it knows best. Most people know where they are on a world map, and anyone who does not won't be able to navigate these huge lists of cities either. (Especially since they often must choose the nearest major city, not their actual location). Further, this would stop being so high maintenance; we wouldn't need to constantly add new locations since the user entering his own data by choosing a point of a map is completely natural and goes with the existing flow. With the location name being auto detected based on latitude and longitude, the whole thing could later plug in to GPS data without a problem. Oh, and the interface would be way simpler. As for weather, that could (And SHOULD) be done completely automatically. For example, the OMWeather applet for Maemo finds the nearest weather station via GPS location data. Is there a weather service yet that can give forecasts based on coordinates, or weather maps, or is the limit of only getting weather for specific locations still deeper than the applet itself? Bye, -Dylan McCall ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
> Personally, we should cede the desktop to other projects like XFCE > that work very well with minimal hardware requirements. I've noticed > a lot of projects in GNOMEFiles with goals to write "lightweight" > panels and what not. 10 years is a reasonable amount of time to > expect hardware requirements to change. Looking forward seems to be > the best course. Not that I have anything against a crazy high-traffic thread making a peaceful conclusion, but I found it odd how this discussion ended as soon as Sri made this awesome point. I, for one, fully agree. It's already the case that users can switch pretty seamlessly between GNOME and XFCE since the two use mostly the same technologies at heart. It could be made smoother, for example bridging Evolution and the calendar / email system XFCE uses. That could be as simple as providing a GNOME Clock Applet clone for xfce that distros could ship. XFCE does an awesome job; it is mature, fast and attractive. Its panel works quite well. It would be really great to see that product treated like a first class alternative instead of duplicating efforts :) Bye Dylan signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Applets in general are broken because they are no different in functionality from regular applications, or from each other (in terms of desklets vs panel applets vs. the notification area). Many applets are applets because they have very small, simple interfaces; too small to justify having big top-level windows, too big to sit entirely in the background. The big usability disaster this distinction creates is that the application menu goes from being The Way to run applications to being A Way to run applications; another bunch of them are run by right clicking on the panel and choosing to add an applet. Lots of applets act as launchers. For example, timerapplet[0]. The user clicks it, it opens a little dialog, the applet becomes a stylish countdown timer with a nice icon. This could have been done differently. Alternatively, timerapplet could be opened from Applications->Accessories, create a notification icon and be reasonably close to the HIG. The problem there is Accessories would become bloated with stuff like Wanda the fish, stock tickers, eyes and alarm clocks, and also timerapplet would be jumping from one corner of the screen (where it's a launcher) to another (where it's a "window"). Hence the panel applets; a dumping ground for accessories that don't quite deserve to take up 30 pixels of vertical space in the Applications menu but can go somewhere else we never expect the user to use. Instead, because timerapplet is too small and insignificant to consume menu space, it is opened with the panel every time the user logs in! (Wait, what?...) Similarly, all sorts of applications choose to hide within the notification area because they want to stay out of the user's way and window managers fail to provide the necessary functionality themselves. Thus, they take window management upon themselves and start playing with system trays. This should remind you, tenacious reader, of tabbed document interfaces, notification-daemon abuse (for fancy looking dialog boxes), anthropomorphic dogs and rabbity things. So here are some questions to answer: What is so vastly inferior about the application menu that necessitates "applet" software to provide another distinct list of less important applications? Why can't we have big and small applications in the same place? I do have a guess what could be done. Firstly, abolish applets as things which must be run differently from other applications; the user should not Ever see the word "applet" again. Enhance running applications and how they connect with application launchers and their windows; one of the things GNOME Shell seems to be doing. Maybe one way about this is to build on that part of the window manager where it's up to The User whether he wants to minimize a window, shade it or put it beside another on the right side of the screen. How about window management hotspots, such as a panel and a sidebar, each with unique properties for how they treat windows? The user places a window in one of those and, depending on whether it supports some fancy extensions, it becomes a docked window like any file in the panel or the desktop (eg: a window icon that when clicked opens into a full window again). Super awesomeness could extend that so the docked window gains desklety / applety functionality when supported. Basically, kill the distinction and leave it up to the user to say what he wants a window to do rather than have them making unpredictable guesses, and have the window - or whatever other object - do what it can to meet the user's commands. [0] http://timerapplet.sourceforge.net/ Thanks, sorry for the hugeness, Dylan McCall PS: I wrote this bit by bit over a couple /days/, so I'm sending this at risk of it being completely incomprehensible. Forgive me if that's the case. Mockup almost at the ready if it'll help. PPS: A nice process here is writing out key features of different parts of the desktop environment which implement window management. Lots of overlap, but also lots of examples for how existing infrastructure can be beefed up as an alternative, tidier solution. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 - shell and applets
> Toms a écrit : > > > 1) System tray - applets that could end up in system tray, most > > probably contextually - like, when they are needed or make sense. Or, > > sometimes per user request in preferences (something like a "show in > > system tray" checkbox for those marginal "nobody knows" cases). As > > pointed out[2], KDE has some specs worth considering on the case. > > Please, don't try to abuse the system tray for things that should be > applets. System tray has been made to notify events. One should be able > to use GNOME without requiring a notification applet. A recent example > of things gone wrong is the volume controler : it should be an applet an > not a system tray item, as it presents a permanent state and not an > event nor a response to an event. > > From > http://library.gnome.org/devel/hig-book/stable/desktop-notification-area.html.en > > > "The utility of the notification area decreases rapidly when more than > about four icons are always present. For this reason, icons that appear > only temporarily in response to events are preferable." This could be countered similarly: Please stop abusing the system tray for notifications, GNOME ;) Sure, the FreeDesktop spec hints at using it for notifications, but that plan is really not well defined so its role ends up very inconsistent between different projects who offer up their own interpretations. The solution is not to create Yet Another Applet / Notification technology and push it on top of the others (which would require a ladder at this point). Right now we have the wonderful newish dbusy desktop notification spec, which really could handle every kind of notification from short-term low priority to permanent (until user dismisses) super high priority along with actions. Why not let that handle the "notification area"? That we we are guaranteed purity because developers have to be pretty darn sure they are notifying of things if they pull out an API called libnotify. As for system tray, the thought seems to be at the back of everybody's mind to kill the current implementation and create something new that unifies the redundant panel applets all the desktop envionments have and perhaps, while at it, removing that redundancy with the window list concept. Ideally something that keeps tray applets arranged by categories and is desktop-neutral. Personally, I think all things applet related should happen nice and close to FreeDesktop before this part of the desktop ecosystem chokes on itself. Bye, Dylan McCall signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: So.... Who's redoing their UI for 2.30/3.0?
On Mon, 2009-09-28 at 16:59 -0400, Joanmarie Diggs wrote: > Hi all. > > I happen to be on the gcalctool list where Robert announced that he'd > begun making some major changes to the UI. Having this much lead time > makes it possible for us to update Orca's support for gcalctool, file > bugs, and when possible submit patches. Orca + gcalctool should be great > for 2.30/3.0 as a result. (Thanks Robert!) > > Since there are undoubtedly countless lists I'm not on Anyone else > making major UI changes? :-) > > Thanks in advance! Take care. > --joanie I would be curious if anyone is touching the UI for AT Preferences, as the current one is bewildering. I had trouble figuring out how to activate Orca and an on-screen keyboard, and I have perfectly fine vision. Questions that came to mind: Why do we expect the user to follow "Preferred Applications" through to activate Orca, why is there another heading called Preferences under Assistive Technologies Preferences, and what exactly is Keyboard Accessibility? (And what's with the icons?!). Was looking at redoing it myself, actually, given that the current situation makes me feel bad, but I wouldn't want to duplicate a more official effort :) -- Dylan McCall signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Appearance properties
> So instead of making this thread bigger, why don't people go to write a > 'Interface' capplet, starting with what there was on the Interface tab? > If it's done correctly, we can even think about including it in > gnome-control-center! :) On that topic, it strikes me as fairly logical to mix a new Interface capplet in with the window preferences. Good luck, whoever does it! Dylan (And for the record, I am very much in favour of this decisiveness in toolbar layout since it will make things easier and more stable for application developers). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: application indicators
> Currently we generate a StatusIcon on the fly by rendering into a > pixbuf. This icon contains the color of the highest event severity > and the number of events of this severity. Using the AppInd model, we > would be required to generate roughly 5k icons just for this display > (5 status colors x numbers 0-999). I know this wouldn't do the whole job, but has anyone considered an addition to the spec that allows adding emblems to StatusIcons? For example, there could be a Play and Pause emblem, and some kind of standard message count emblem that gets drawn on the fly. (With the added benefit that a text-centric interface could also show the message count since the necessary data is all there). If it hasn't been discussed, maybe worth some pondering, and if it has in recent history, I for one would love to know the verdict :) Thanks, Dylan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: application indicators
> > If it hasn't been discussed, maybe worth some pondering, and if it has > > in recent history, I for one would love to know the verdict :) > > I don't think I've discussed it with regards to Application Indicators, > but the issue that I've always had with emblems is that they look > "bolted on." So overall, the design looks sloppy even if both the icon > and the emblem look nice on their own. In theory, this is solvable, but > I've never seen a solution that looked good and seemed less complex than > just drawing all the icons that were needed. > > It could be that no one has done it right. Do you know of an > implementation that you feel did a really good job on this? > > --Ted > Hi Ted, My favourite example right now is Google Chrome's Badges interface for browser action extensions. Extensions control the colour of the badge and the text in it (up to three characters), and that is all. Chrome places that badge to the lower right corner of the extension's toolbar icon. Visually it feels rather clean (in my opinion) because there is a lot of white space around each extension icon. So, the badge barely overlaps the icon and mostly occupies space that was empty. Of course, they have the advantage that it's all shiny new stuff so there is a single set of guidelines for how toolbar icons should look. Dylan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
I think it would be worth fleshing out some existing parts of the design, like the application menu and launchers, before delving in to gizmos as a separate component. In the end, if the rest is done to cover the appropriate jobs, they may not be necessary. One really dumb thing with gnome-panel applets today is that, in a lot of ways, we're arbitrarily categorizing these applications differently (because they're small) and putting them in a horrible menu that can't be accessed through primary interactions. Instead of being in, say, Applications›Finances, to get a cute stock ticker that's always available you need to right click the panel, choose "Add to Panel…" and search, and then position the applet somewhere. It's really totally arbitrary! Lots of smartphone OSs solve this with things like badges attached to application launchers. That approach alone seems to work very well. Gnome-shell, meanwhile, has a lot of pixels to play with ;) Thanks, Dylan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]
I wasn't intending to jump into this because it has become vastly tangential and there's a pretty unhappy signal to noise ratio already. So, I realize I might be totally misunderstanding this. If I sound accusatory or anything, it's purely my writing getting carried away :) Here goes… In any Gnome 2 desktop that has been loved, the System menu has many applications which do not exist upstream. An integrated control centre gives users a nice way to find those applications on the basis that they are accessed for similar reasons: configuring services and things that relate to the entire system (where each panel might affect more than one device, hence keywords). Okay, that sounds good. Gnome 3's Control Centre _is_ really good. However, from the sounds of it, this isn't actually fixing our problem. This isn't replacing the system menu, or providing any kind of top level order. It configures Gnome, and only Gnome. From here arises a pretty serious question: what does Gnome have to do with my screen resolution, and what am I to do if I am using NVidia's proprietary driver which comes with nvidia-settings? I no longer have the System menu, and apparently this won't be in Control Centre either. Either Gnome needs to keep up with everything nvidia-settings does, nvidia-settings needs to be an official Gnome module, or our users need to search for nvidia-settings as if it is any other application (eg: in the Applications section of the Activities overlay). On this same vein, it sounds like users will need to know what Gnome is and that Control Centre configures Gnome if they expect to find the particular configuration panel they are looking for. Am I on the right track here? -- Dylan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GObject Introspection instead of PyGTK
On Wed, Nov 2, 2011 at 12:59 PM, Jasper St. Pierre wrote: > There's a good introduction over here: http://python-gtk-3-tutorial.rtfd.org > > The first thing that I would do is replace: > > import gtk > import gobject > > with something like: > > from gi.repository import Gtk as gtk, GObject as gobject > > and see what breaks. You can also find a porting guide over here: https://live.gnome.org/PyGObject/IntrospectionPorting Indeed, the first step is just renaming stuff. There's a bunch of that, and in some cases it might be all you need to do. Good luck! Dylan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Be respectful and considerate. A complaint.
On Mon, Jul 2, 2012 at 2:12 PM, Andreas Nilsson wrote: > For reference, here is the extra pane functionality in Nautilus: > http://andreasn.myownb3.com/temp/nau-extra-pane.png > > And here is the same feature, but at the window manager level (and for all > the other apps too): > http://andreasn.myownb3.com/temp/nau-side-by-side.png > > Same thing, just on a different level and now desktop-wide. Thanks for posting that. It's a really interesting comparison :) There are just a few things we could do with split-view Nautilus that we cannot (currently) do with the window manager: 1. Resize the two panes. 2. Do this with a movable, unmaximized window. (Eg: do this reasonably on a large screen). 3. Enable split view with a single keystroke. For #1, I think that is something the window manager could totally do. Chrome OS currently does the same and it's been pretty well regarded, and it can't be _that_ hard to implement. (Is it?). #2 wouldn't be unheard of from a WM level, either, though it might be a little tricky to get right. Haiku OS has a really interesting window manager with this type of functionality: http://www.haiku-os.org/docs/userguide/en/gui.html. #3 is arguably not _too_ different here. You can get a split view with Super+Left, Ctrl+N, and Super+R (for the new window). That isn't discoverable, though, and it certainly won't be shown as "View extra pane" in a nice menu somewhere. So, I think your example shows where there's a good opportunity to make the GNOME platform amazing to develop on. For a developer, it would be brilliant to just get all kinds of view management features for free after doing some basic multi-window stuff. (Android's Fragments API is perhaps good inspiration here). But, as much as I love the 'let the window manager take care of it' approach, right now the user experience is losing out. Applications tend to be completely subservient to the window manager, and the window manager knows very little about applications. (Definitely improved in GNOME Shell, but it's still fairly limited). >From the WM level, I'm pretty sure we can't do F3 to get split Nautilus windows in any reasonable way. (We don't know if an app will support that, and we can't tell an app to open a window just like its current one). But perhaps that be done with a helpful function in an API somewhere. For any application where split view would make sense, it could use that API call and tie it to a menu item with F3 as an agreed-upon keyboard shortcut. So for the end user split view in Nautilus could be initiated just like it is now, but for a developer it would dead easy. Okay, rambling over. Dylan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
What can you tell new about Content Selection?
I remember reading about a goal for GNOME called "Content Selection". One of those new-fangled content applications like Files, Photos or Documents would be available as a Content Selector (much like a file chooser dialog) for any other application. Here's Allan Day on the subject, and a wiki page: http://afaikblog.wordpress.com/2012/05/10/gnome-design-update-part-two/ https://live.gnome.org/GnomeOS/Design/Whiteboards/ContentSelection Now, first of all, I guess I'm wondering if this is on a roadmap somewhere, or if it's just an idea at this point. Either way, this is something I have been very interested in for some time, and I've been meaning to play with GNOME a lot more, so I would really love to do something to help make it happen :) Is somebody working on Content Selection at this point, and do you think it would make sense for a student to contribute to that as a GSoC project? (Willing mentors, etc?). Who should I talk to? Any help is greatly appreciated. Dylan McCall ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What can you tell new about Content Selection?
On 8 Apr 2013 16:01, "Federico Mena Quintero" wrote: > > As far as I know, this is not being worked on yet. Some months ago I > started a very preliminary (read: nearly useless) API brainstorming page > here: > > https://live.gnome.org/GTK%2B/ContentSelection > > (... which I noticed wasn't linked from the design page - fixed now.) > > It would be good to sit down and chat about this. Would you like to do > this as a GSoC project? I'd very gladly mentor you! > > Federico > You read my mind, Federico - yes, I would LOVE to work on this as a GSoC project! Sounds like such a project has a lot of room to play in - some specification-writing, some library-writing, some example implementations with various apps, and maybe a bit of evangelising… - so it would be important to come up with a good scope for it. I think it's interesting that your API brainstorm page takes a totally different tack from what I had been picturing, and from what I often see elsewhere. (That involved lots of MIME types and the possibility of apps providing types of content we haven't thought about, like GPX files or calendar events - which, come think of it, could work pretty badly in practice). So, I like it :) I would definitely like to chat about this with you. I'm in final exam panic mode this week so I won't be much fun, but maybe early next week I'll find you on IRC? Thanks for all the help! Dylan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome-panel: "Always beneath" property
n
of an "always beneath" panel. Hoping that is fixable, because it can be
confusing...
-An "always beneath" panel will snap to the edge of the screen when
repositioned, possibly disappearing behind an always on top panel. (It
should instead snap to the inside edge of that panel!). This seems a problem
already showing its face elsewhere with panels that are not expanded when
they are moved similarly. In general, this is not a problem except if
somebody wants a really big "always beneath" panel lined up with another big
panel that stays on top. I could blame the user all I want, but it would be
nice if this could be fixed. (Note that this, like the last, is fixable by
turning on struts. If we could have something like those struts affecting
only certain types of windows, that would be good).
-Trivial, but the maximum panel size in panel properties is 120 pixels. One
can set it higher in the gconf editor. Is there a reason for this?
-There are so far no applets really suitable to the "desklet" use case. I am
sure if that sort of thing became possible with the panel, more significant
applets would not be too far away.
I might add that this is my 4th day ever caring about xlib; a good sign that
there are ways around these problems which I do not know!
Also, if anyone has any suggestions about that label ("Always beneath"),
feel free to speak them. I came up with that in a hurry, and it doesn't
really flow off the tongue like "Always on top" seems to. It ended up with
an ugly accelerator key, to boot.
I shouldn't restrict the openings for ideas, though... I am looking forward
to any thoughts here at all!
I have some screenshots and use cases, uploaded to Google Picasa for some
weird reason...
http://picasaweb.google.co.uk/DylanMcCall/GnomePanel
If you are not yet fatigued by my writing, please note the captions on those
images.
This is really a pretty trivial change under the hood, but I think giving
this tiny bit of extra functionality to gnome-panel would be really
worthwhile. The added functionality is significant, with very little hit on
usability.
Bye,
Dylan McCall
PS:
I was about to attach a patch, but I just remembered I haven't tested this
with the trunk build. (I developed and tested it on 2.18, then moved it
upwards. Looks like it will work, but I may as well be safe and build the
thing).
In that case I should really have just left this message for a while since
that renders a chunk of it useless, but, as you can see, I am quite
impatient sometimes. I look forward to your responses!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Documents on the Online Desktop
any web service. The actual implementation of such a thing would probably be a horrifying monstrosity, but there is one way to get collaborative content without needing to upload it to an irrelevant service in the centre. It would be great if we could easily (in one step) use our own preferred tools that are already there on the desktop, instead of adding on a detached web service to do a single extra task. Local applications can already do most of this new-fangled web application stuff, and the exceptions are things that should be addressed by improving the existing infrastructure -- Not by stretching the already stretched web infrastructure. Bye (and I hope that wasn't too rambly), -Dylan McCall On 8/28/07, Havoc Pennington <[EMAIL PROTECTED]> wrote: > > Hi, > > On 8/28/07, Steven Garrity <[EMAIL PROTECTED]> wrote: > > 2. Organization - rather than a fixed desktop metaphor with a set of > > folders (which I had been quite satisfied with until now), Google Docs > > organizes your documents more like email (or Gmail, I suppose) with the > > most recently edited/created docs at the top of the list. > > Yes! Interestingly, this is similar to the "journal" idea that One > Laptop Per Child uses. It's so much better than screwing with folders. > (I noticed that I use my desktop background as a lame "journal," since > saved files accumulate in order.) > > > If I was to take anything from this, it would be that I don't want the > > wall to exist between my "desktop documents" that I have created and > > edited on my own PC (with OpenOffice, Inkscape, etc.) to be completely > > segregated from any docs I create with an online service. I'm not sure > > how, but it seems that a document I create on my desktop should show up > > in my google docs and vice-versa. > > Yes again! I have looked at this in fact. There are two approaches > that both don't work. Approach one would be to get the feed of > documents from Google, and merge them with local docs and display all > of the documents locally or at your online.gnome.org account. > > Fatal flaw in approach one is that Google has no API to get the > documents, only to get the spreadsheets. > > Approach two would be to upload documents to google, and the fatal > flaw is they have no API for that. > > We can't fix this since the google stuff isn't open source, but maybe > they will address one or both issues eventually. > > For me if I could get PDFs merged with my google docs that would > pretty much cover it, I don't have anything else ever. > > Havoc > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
