Re: gnome-utils branched for GNOME 2.16
On 9/4/06, Emmanuele Bassi [EMAIL PROTECTED] wrote: Plans for the 2.17/2.18 cycle (many recycled from the 2.15/2.16 cycle): snip * If available, add single instance support to the Dictionary using the GUnique library; Note that the GUnique library depends on a patch not yet merged into gtk+[1]; also it looks like we're going to be shooting for gtk+ 2.12 in Gnome 2.20 rather than 2.18[2]. So you will probably have to defer this part of your plans. Elijah [1] http://bugzilla.gnome.org/show_bug.cgi?id=347375 [2] http://mail.gnome.org/archives/gtk-devel-list/2006-September/msg00141.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
On 9/21/06, Elijah Newren [EMAIL PROTECTED] wrote: On 9/4/06, Emmanuele Bassi [EMAIL PROTECTED] wrote: Plans for the 2.17/2.18 cycle (many recycled from the 2.15/2.16 cycle): snip * If available, add single instance support to the Dictionary using the GUnique library; Note that the GUnique library depends on a patch not yet merged into gtk+[1]; also it looks like we're going to be shooting for gtk+ 2.12 in Gnome 2.20 rather than 2.18[2]. So you will probably have to defer this part of your plans. Um, oops... Richard just pointed out to me how I had forgotten that Vytas had done a very good job making the GUnique library work as well as possible with gtk+-2.10. So, you can still implement it this cycle. Some notes: 1) Richard has imported the GUnique library as libgunique in cvs; he has been applying some patches to improve it and will be applying some more (e.g. to make it a shared library). 2) gnome-power-manager has an example of how to use libguniqueapp in gnome-power-manager/src/gpm-prefs.c, which is a relatively short file. (See bug 357128 first, though!). Other examples can be found in the links from http://bugzilla.gnome.org/show_bug.cgi?id=351941. 3) There's subtle gotchas when using gtk+-2.10 (see e.g. http://bugzilla.gnome.org/show_bug.cgi?id=357128). If you want, you can ping me and I'll try to review any patches you have. 4) Using libguniqueapp with gtk+-2.10 will result in some race conditions, but none are severe by any means. It's more than likely going to be less problematic than what you're already using. Hope that helps, Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
Third time's a charm, or so I hope... On 9/21/06, Elijah Newren [EMAIL PROTECTED] wrote: snip 2) gnome-power-manager has an example of how to use libguniqueapp in gnome-power-manager/src/gpm-prefs.c, which is a relatively short file. (See bug 357128 first, though!). Other examples can be found in the links from http://bugzilla.gnome.org/show_bug.cgi?id=351941. Er, *the links from http://bugzilla.gnome.org/show_bug.cgi?id=351092* (of which bug 351941 is just one example in the dependency list). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
On Wed, 6 Sep 2006, Bryan Clark wrote: The first, obvious transition is to a save dialog window with the same behaviour of the GtkFileChooserDialog, to use the tab completion + full path editing of the destination file; the currently used layout (preview + save stuff + (save, cancel, help) buttons can be bolted without much effort on a GtkDialog with an embedded GtkFileChooserWidget in save mode. This is the structural change that I have in mind at the moment. Using a vertical layout might be the next move - I think there's too much wasted screen real estate in the current dialog. I think the tab completion is probably a good idea. I hope you mean the same standard autocomplete as the file chooser but write tab completion out of force of habit, because tab completion breaks the use of tab to move through a dialog. Also I hope you are using the gimp as an example of edit or open with functionality and do not plan to mention a specific program within the screen shooter. -- Alan H. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
På Tue, Sep 05, 2006 at 11:41:03AM -0400, JP Rosevear skrev: On Mon, 2006-09-04 at 13:17 -0500, Shaun McCance wrote: On Mon, 2006-09-04 at 12:22 +0100, Emmanuele Bassi wrote: Hi Jeff; On Mon, 2006-09-04 at 21:01 +1000, Jeff Waugh wrote: quote who=Emmanuele Bassi At the moment, it is fairly difficult to do a window selection unless you know the secret password (key combo or CLI parameters). An optional two step process (made optional by defaulting to full screen as it works now) would help with that. The problem is that I really don't know how to make the Screenshot utility work with a two-step flow without having people screaming at my doorstep because I disrupted their one-step flow. :-) And I quite agree with them: taking a shot of the screen should require the least possible iterations, especially if you want to take loads of shots. I've outlined a proposal for this at least twice, but I can't find the original emails, so I'll do it again. When you call up the screenshot utility from the Applications menu, it should bring up a dialog asking you what you want to do. The dialog would look something like this: || | ( ) Take screenshot of entire screen. | | * Use PrntScrn to do this at any time. | || | ( ) Take screenshot of a single window.| | * Use Alt+PrntScrn to do this at any time. | || | [Cancel] [Shoot] | || Needs a delay option as well probably. ie wait 3 seconds and then take the shot. That would be a welcome addition, yes. However, please make it a global option in the dialog instead of the double timeout widgets in Gimp's 2.2 series... mvrgr, Wouter -- :wq mail [EMAIL PROTECTED] web http://uwstopia.nl you're a carbon kid with a sinister diagram -- alpinestars/brian molko signature.asc Description: Digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
Wouter Bolsterlee wrote:
På Tue, Sep 05, 2006 at 11:41:03AM -0400, JP Rosevear skrev:
On Mon, 2006-09-04 at 13:17 -0500, Shaun McCance wrote:
On Mon, 2006-09-04 at 12:22 +0100, Emmanuele Bassi wrote:
Hi Jeff;
On Mon, 2006-09-04 at 21:01 +1000, Jeff Waugh wrote:
quote who=Emmanuele Bassi
At the moment, it is fairly difficult to do a window selection unless you
know the secret password (key combo or CLI parameters). An optional two
step
process (made optional by defaulting to full screen as it works now) would
help with that.
The problem is that I really don't know how to make the Screenshot
utility work with a two-step flow without having people screaming at my
doorstep because I disrupted their one-step flow. :-) And I quite agree
with them: taking a shot of the screen should require the least possible
iterations, especially if you want to take loads of shots.
I've outlined a proposal for this at least twice,
but I can't find the original emails, so I'll do
it again.
When you call up the screenshot utility from the
Applications menu, it should bring up a dialog
asking you what you want to do. The dialog would
look something like this:
||
| ( ) Take screenshot of entire screen. |
| * Use PrntScrn to do this at any time. |
||
| ( ) Take screenshot of a single window.|
| * Use Alt+PrntScrn to do this at any time. |
||
| [Cancel] [Shoot] |
||
Needs a delay option as well probably. ie wait 3 seconds and then
take the shot.
That would be a welcome addition, yes. However, please make it a global
option in the dialog instead of the double timeout widgets in Gimp's 2.2
series...
Wow, it's gnome-utils branch deja vu all over again! [1] :)
I think it's time to take a couple steps back from this and talk about
the experience you're expecting to enable with the screenshot app.
We're starting to wind down the hole of adding in features and I'm not
sure where we're going with it. I'm pretty sure I designed the current
screenshot dialog last year or so with jrb and our goal was to let you
quickly see the preview of your screenshot, the file name and the
directory that file would be saved to. The use case was something like
shaunm or other people who are taking a number of screenshots of
different windows and the whole desktop and I think we nailed that
pretty well.
Of course this addition is only for the the application menu launch
which I think is a nice trick to help out new people and advanced
users. However on my long drive to work this morning I was wondering if
we couldn't just take individual screenshots of the applications as well
as a whole screenshot all at once. Doesn't composite or something allow
this? I mean we don't have flying cars yet in 2006, but I was hoping we
could at least get this little improvement. And I think it would help
everyone (first time screenshotters, plus advance types) if the
screenshot dialog just gave me a screenshot of the whole desktop plus
individual screenshots of each application. Maybe it allows me to
select which one I'd like to save?
I'm not saying a delay option wouldn't be a good thing as well. Perhaps
we include a [Take another with a {5} second delay] button so you can
reset windows and such. But what we need is to discuss a little bit of
how we expect people to use this and what for. Shaun had a great email
explaining his use of the screenshot tool from back in feb. [2], that's
the kind of discussion that will allow us to see the problems we need to
solve from the actions we have the ability to implement.
Myself, I use the screenshot tool a lot as well. My use case is mostly
taking a screenshot of a specific web page or application and then using
the GIMP on the screenshot to extract some image or widget I need from
the shot. Often I'm taking a couple screenshots and doctoring up some
mockups that are based off an initial application. For me the
screenshot tool works pretty well for this, I would like some faster way
to work with a screenshot in GIMP after I've taken it, however I think
that needs to be done outside of the screenshot dialog. [3] Very seldom
do I need a delay to setup up a screenshot, back when I was working on
NetworkManager I needed that delay to catch the drop down menu so we
could design what would be inside of it. However the realization that I
couldn't screenshot the drop down menu without a delay always came after
the fact that my first screenshot didn't work. I was thinking a delay
button in the dialog would help with this. Perhaps this means we could
change alt-prntscrn to be the
Re: gnome-utils branched for GNOME 2.16
Hi Bryan; On Wed, 2006-09-06 at 11:49 -0400, Bryan Clark wrote: That would be a welcome addition, yes. However, please make it a global option in the dialog instead of the double timeout widgets in Gimp's 2.2 series... Wow, it's gnome-utils branch deja vu all over again! [1] :) Indeed. :-) Last time the thread died out pretty quickly, and since I had to push back the UI work on the screenshot app, I'd like to nail it down for real this time. The first, obvious transition is to a save dialog window with the same behaviour of the GtkFileChooserDialog, to use the tab completion + full path editing of the destination file; the currently used layout (preview + save stuff + (save, cancel, help) buttons can be bolted without much effort on a GtkDialog with an embedded GtkFileChooserWidget in save mode. This is the structural change that I have in mind at the moment. Using a vertical layout might be the next move - I think there's too much wasted screen real estate in the current dialog. I think it's time to take a couple steps back from this and talk about the experience you're expecting to enable with the screenshot app. We're starting to wind down the hole of adding in features and I'm not sure where we're going with it. I'm pretty sure I designed the current screenshot dialog last year or so with jrb and our goal was to let you quickly see the preview of your screenshot, the file name and the directory that file would be saved to. The use case was something like shaunm or other people who are taking a number of screenshots of different windows and the whole desktop and I think we nailed that pretty well. Yep, and it works well - also, having drag and drop support makes the edit in GIMP button feature kind of a moot point: I can drag the preview on GIMP and have it ready to be edited. This might pose a problem for the a11y people, though. Of course this addition is only for the the application menu launch which I think is a nice trick to help out new people and advanced users. However on my long drive to work this morning I was wondering if we couldn't just take individual screenshots of the applications as well as a whole screenshot all at once. Doesn't composite or something allow this? I mean we don't have flying cars yet in 2006, but I was hoping we could at least get this little improvement. And I think it would help everyone (first time screenshotters, plus advance types) if the screenshot dialog just gave me a screenshot of the whole desktop plus individual screenshots of each application. Maybe it allows me to select which one I'd like to save? This could be a nice idea. I'll open a bug to block on, with a dump of the UI ideas of the thread, but I'd like more comments on it; I'll also blog about it. [3] I'm pretty sure there's a bug somewhere I got CC'd on about opening screenshots directly into GIMP, I feel like this is the wrong place for that. Instead I think we could do something like tagging a screenshot with 'screenshot' category and GIMP should be aware of new screenshots created when I go to use it (just an idea). This is part of the recent files support that I'd like to add to the screenshot app now that we have the API in GTK+; adding a custom Screenshot when saving a screenshot is not a big deal. Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
Hi; On Wed, 2006-09-06 at 15:59 -0400, Bryan Clark wrote: Last time the thread died out pretty quickly, and since I had to push back the UI work on the screenshot app, I'd like to nail it down for real this time. The first, obvious transition is to a save dialog window with the same behaviour of the GtkFileChooserDialog, to use the tab completion + full path editing of the destination file; the currently used layout (preview + save stuff + (save, cancel, help) buttons can be bolted without much effort on a GtkDialog with an embedded GtkFileChooserWidget in save mode. This is the structural change that I have in mind at the moment. Using a vertical layout might be the next move - I think there's too much wasted screen real estate in the current dialog. I think the tab completion is probably a good idea. I'm wary of going more towards a unified and consistent system vs. doing hacks that simply make the screenshot dialog better. For instance I believe someone mentioned in a previous mail that the fact that the file extension is included in this entry is a bit cumbersome. You can't save as a jpg or gif here so it's no use to require me to type in 'png', I hope that doesn't get inherited from using the filechooser widget. The extension is not selected by default so you have to actively select it to change it; but the ability to save a screenshot as a type supported by GdkPixbuf is another feature on the wish list for a while, now. [...] The wasted screen real estate argument in this case is more about the lack of a balance between the preview and the controls; it shows in the mock up you attached: you've got a pretty big picture and two small-ish controls on the left with a huge empty space. I don't want to fill up that space with controls, knobs, text, whatever; I'd like the dialog to have a more fair balance between the elements inside it. Not to say that there couldn't be cleaning up of the dialog. But one of the elements I'd like see kept in the design is the left to right flow of the dialog; this of course isn't internationalized. We put the screenshot preview on the left side of the dialog because when it first opens you want to examine the screenshot preview first, then handle changing the filename, then the lower buttons. I don't have any eye tracking usability tests to prove this is working, but that was the intent of the design. We had prototyped a number of mockups that I aparently can't find now. But if the dialog gets rearranged to have the preview on the right hand side and all the other widgets on the left it requires a person to scan over the whole dialog to check the preview, then scan back to where they change the filename, then scan back over to find the save button. I was more attracted by the vertical layout, with the preview on top - a bit larger than what it is now - and the actual FileChooserWidget below it. There's an ASCII art mock-up attached on a bug here[1], and I attached a couple of PNGs[2] of how I think it should work both with vertical and horizontal layouts. The FileChooserWidget sizing represents a problem in both cases, so we're going to need a minimum size and test on lower resolutions. Anyway, if we are to keep the current layout (image first, save control after) then we must really rearrange it based on the text direction: as you wrote, the whole point of having the current layout is to ease the user into following a certain flow, mimicking the reading pattern. Yep, and it works well - also, having drag and drop support makes the edit in GIMP button feature kind of a moot point: I can drag the preview on GIMP and have it ready to be edited. This might pose a problem for the a11y people, though. Wow, I actually had no idea you could do that. That tends to save a bit of time. Perhaps it would be worthwhile to let people know that is possible with a simple text area, see attached. Indeed. I already had to tell a couple of people that there was this feature. :-) So yes, definitely a help hint is needed. +++ [1] http://bugzilla.gnome.org/show_bug.cgi?id=325708#c6 [2] http://bugzilla.gnome.org/attachment.cgi?id=72345action=view and following Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
On Mon, 2006-09-04 at 21:50 +1000, Jeff Waugh wrote: quote who=Alan Cox Xv from fifteen years ago except for the lassoo. I didn't want to rub it in. We could even integrate video screencast creating tools into the default screenshot tool (such as Byzanz, Istanbul, or a combination of the two so we can do GIF and GStreamer video codecs). Should that not be in with the existing tools for doing VNC ? That's kind of a different problem - if we had a nice VNC client, we could add sshot/video support to it. But thus far, we don't. :-) These tools do current-display recording, which I imagine is more interesting to more people. writing a nice frontend for vncviewer shouldn't be hard at all, should it? -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
On Mon, 2006-09-04 at 13:17 -0500, Shaun McCance wrote: On Mon, 2006-09-04 at 12:22 +0100, Emmanuele Bassi wrote: Hi Jeff; On Mon, 2006-09-04 at 21:01 +1000, Jeff Waugh wrote: quote who=Emmanuele Bassi At the moment, it is fairly difficult to do a window selection unless you know the secret password (key combo or CLI parameters). An optional two step process (made optional by defaulting to full screen as it works now) would help with that. The problem is that I really don't know how to make the Screenshot utility work with a two-step flow without having people screaming at my doorstep because I disrupted their one-step flow. :-) And I quite agree with them: taking a shot of the screen should require the least possible iterations, especially if you want to take loads of shots. I've outlined a proposal for this at least twice, but I can't find the original emails, so I'll do it again. When you call up the screenshot utility from the Applications menu, it should bring up a dialog asking you what you want to do. The dialog would look something like this: || | ( ) Take screenshot of entire screen. | | * Use PrntScrn to do this at any time. | || | ( ) Take screenshot of a single window.| | * Use Alt+PrntScrn to do this at any time. | || | [Cancel] [Shoot] | || Needs a delay option as well probably. ie wait 3 seconds and then take the shot. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
Forgot to Cc: some people On Mon, 2006-09-04 at 11:13 +0100, Emmanuele Bassi wrote: Hi all; I've just branched gnome-utils for the stable cycle. The branch is called gnome-2-16; all new development will happen on HEAD. Plans for the 2.17/2.18 cycle (many recycled from the 2.15/2.16 cycle): * Add dictionary source editor to Dictionary; * Add speller widget to the Dictionary applet; * Port Dictionary to GtkPrint and drop libgnomeprint requirement; * If available, add single instance support to the Dictionary using the GUnique library; * Switch Screenshot to a full GtkFileChooser dialog and provide the UI it as a shared library for other applications to use; * Clean up logview code base; * Add a plug-in based log source/processing functions to logview; * Add new default graph to Baobab; Other plans might be added during the cycle on the GnomeUtils wiki page at: http://live.gnome.org/GnomeUtils/RoadMap Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
Hi Jeff; On Mon, 2006-09-04 at 21:01 +1000, Jeff Waugh wrote: quote who=Emmanuele Bassi * Switch Screenshot to a full GtkFileChooser dialog and provide the UI it as a shared library for other applications to use; Have you seen the Windows Vista screenshot tool? The basic UI is pants, but it offers some cool features that we could swipe: * Full screen * Window selection (click to choose) This could be relatively easy to implement... * Rectangular selection ... while this has its own bug number: http://bugzilla.gnome.org/show_bug.cgi?id=155061 * Lassoo selection (relatively crackful) Mmh, I this this is really too much crack to be worth it; selecting the screenshot area using a rubberband-like selection should be enough. At the moment, it is fairly difficult to do a window selection unless you know the secret password (key combo or CLI parameters). An optional two step process (made optional by defaulting to full screen as it works now) would help with that. The problem is that I really don't know how to make the Screenshot utility work with a two-step flow without having people screaming at my doorstep because I disrupted their one-step flow. :-) And I quite agree with them: taking a shot of the screen should require the least possible iterations, especially if you want to take loads of shots. We could even integrate video screencast creating tools into the default screenshot tool (such as Byzanz, Istanbul, or a combination of the two so we can do GIF and GStreamer video codecs). There was a patch integrating GStreamer ximagesrc sink: http://bugzilla.gnome.org/show_bug.cgi?id=304933 it was for GStreamer 0.8, so it should be ported to 0.10 first; also, the ximagesrc sink can be used to drop the whole shebang of X functions currently used to take a screenshot. (I mention it because it sounds like going to a full GtkFileChooser dialog means strengthening the one step process workflow.) Actually, it means fixing the UI which now behaves *almost* like a FileChooser but not quite - and confuses users. I had planned the UI change during 2.15, but between work, moving between countries and the wedding I could not get around and finish it. Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
quote who=Emmanuele Bassi At the moment, it is fairly difficult to do a window selection unless you know the secret password (key combo or CLI parameters). An optional two step process (made optional by defaulting to full screen as it works now) would help with that. The problem is that I really don't know how to make the Screenshot utility work with a two-step flow without having people screaming at my doorstep because I disrupted their one-step flow. :-) And I quite agree with them: taking a shot of the screen should require the least possible iterations, especially if you want to take loads of shots. I mentioned above that the second step can be made optional, simply by doing what we're already doing - take a full screen shot by default, but prompt to use other tools as well as saving. So if you're taking full screen shots (by pressing PrintScreen) or current-window shots (by pressing Alt-PrintScreen), your workflow is not interrupted at all. But if you want to grab a region, select a window, or take a video, you can clicky-click to the next step (which brings you back to the ready to save window again anyway). We could even add further modifiers to PrintScreen to default to regions or videos or... ;-) - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ I can't imagine anyone telling Emma Bunton to shut up. It would be rather like slapping Bambi. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
On Mon, 2006-09-04 at 21:01 +1000, Jeff Waugh wrote: quote who=Emmanuele Bassi * Switch Screenshot to a full GtkFileChooser dialog and provide the UI it as a shared library for other applications to use; Have you seen the Windows Vista screenshot tool? The basic UI is pants, but it offers some cool features that we could swipe: * Full screen * Window selection (click to choose) * Rectangular selection * Lassoo selection (relatively crackful) At the moment, it is fairly difficult to do a window selection unless you know the secret password (key combo or CLI parameters). An optional two step process (made optional by defaulting to full screen as it works now) would help with that. We could even integrate video screencast creating tools into the default screenshot tool (such as Byzanz, Istanbul, or a combination of the two so we can do GIF and GStreamer video codecs). this looks a much better UI for Istanbul than what it currently (= last time I tried it) has, an icon on the tray. Count my vote on this :-) -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
Ar Llu, 2006-09-04 am 21:01 +1000, ysgrifennodd Jeff Waugh: Have you seen the Windows Vista screenshot tool? The basic UI is pants, but it offers some cool features that we could swipe: * Full screen * Window selection (click to choose) * Rectangular selection * Lassoo selection (relatively crackful) Xv from fifteen years ago except for the lassoo. We could even integrate video screencast creating tools into the default screenshot tool (such as Byzanz, Istanbul, or a combination of the two so we can do GIF and GStreamer video codecs). Should that not be in with the existing tools for doing VNC ? Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
quote who=Alan Cox Xv from fifteen years ago except for the lassoo. I didn't want to rub it in. We could even integrate video screencast creating tools into the default screenshot tool (such as Byzanz, Istanbul, or a combination of the two so we can do GIF and GStreamer video codecs). Should that not be in with the existing tools for doing VNC ? That's kind of a different problem - if we had a nice VNC client, we could add sshot/video support to it. But thus far, we don't. :-) These tools do current-display recording, which I imagine is more interesting to more people. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ Mr Hunt also admits he does not like the expression 'diddly squat', though he will not be ruling it to be unparliamentary. - ABC News Online ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
On Mon, Sep 04, 2006 at 09:33:29PM +1000, Jeff Waugh wrote: quote who=Emmanuele Bassi At the moment, it is fairly difficult to do a window selection unless you know the secret password (key combo or CLI parameters). An optional two step process (made optional by defaulting to full screen as it works now) would help with that. The problem is that I really don't know how to make the Screenshot utility work with a two-step flow without having people screaming at my doorstep because I disrupted their one-step flow. :-) And I quite agree with them: taking a shot of the screen should require the least possible iterations, especially if you want to take loads of shots. I mentioned above that the second step can be made optional, simply by doing what we're already doing - take a full screen shot by default, but prompt to use other tools as well as saving. So if you're taking full screen shots (by pressing PrintScreen) or current-window shots (by pressing Alt-PrintScreen), your workflow is not interrupted at all. But if you want to grab a region, select a window, or take a video, you can clicky-click to the next step (which brings you back to the ready to save window again anyway). Rectangle select has been on my work TODO list for a while. Unfortunately I've not gotten around to it. I imagined it would work much like how Jeff described. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
On Mon, 2006-09-04 at 11:50 +0100, Emmanuele Bassi wrote: Forgot to Cc: some people On Mon, 2006-09-04 at 11:13 +0100, Emmanuele Bassi wrote: Hi all; I've just branched gnome-utils for the stable cycle. The branch is called gnome-2-16; all new development will happen on HEAD. Plans for the 2.17/2.18 cycle (many recycled from the 2.15/2.16 cycle): snip * Switch Screenshot to a full GtkFileChooser dialog and provide the UI it as a shared library for other applications to use; snip Do you have an opened bug for that one? I regularly receive make the Totem screenshot window look like the GNOME one bugs, usually after I've released Totem for a particular version, and would like to CC: myself on it. Cheers -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
On Mon, 2006-09-04 at 21:01 +1000, Jeff Waugh wrote: * Full screen * Window selection (click to choose) * Rectangular selection We had these in GNOME 1 didn't we? Along with the ability to set a timer. I think that bringing up a dialog to offer the user the choice is fairly acceptable. We had that on RISC OS 3. I was really surprised when the Take screenshot option in the Applications-Accessories menu just went ahead and did it. Can't we just have a UI like the GIMP acquire dialog? How about this for a suggestions: * Print Screen key just acts as before * Same re Alt-PrntScr (wow I didn't know that existed...) * Shift-PrntScr brings up dialog * From menu we get dialog For most people hitting the expected key will do the right thing in the spur of the moment. Choosing something from a menu and getting a dialog is not odd at all. Cheers, Rob -- Rob Bradford [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
On Mon, 2006-09-04 at 14:38, Rob Bradford wrote: Can't we just have a UI like the GIMP acquire dialog? How about this for a suggestions: * Print Screen key just acts as before * Same re Alt-PrntScr (wow I didn't know that existed...) * Shift-PrntScr brings up dialog I can never remember that Alt-PrtScreen when I need it (I'm often trying Ctrl-PrtScreen and Shift-PrtScreen first). A little widget in the UI to crop the picture would be more that welcome. Xav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
On Mon, 2006-09-04 at 14:48 +0200, Xavier Bestel wrote: On Mon, 2006-09-04 at 14:38, Rob Bradford wrote: Can't we just have a UI like the GIMP acquire dialog? How about this for a suggestions: * Print Screen key just acts as before * Same re Alt-PrntScr (wow I didn't know that existed...) * Shift-PrntScr brings up dialog I can never remember that Alt-PrtScreen when I need it (I'm often trying Ctrl-PrtScreen and Shift-PrtScreen first). A little widget in the UI to crop the picture would be more that welcome. Even more so for keyboards that don't have PrtScreen (like a MacBook) where the only thing you can use is the screenshot menu item. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an ungodly Catholic librarian on the edge. She's a wealthy motormouth lawyer on her way to prison for a murder she didn't commit. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
quote who=Emmanuele Bassi I had planned the UI change during 2.15, but between work, moving between countries and the wedding I could not get around and finish it. Meanwhile, and interesting comment: http://www.flickr.com/photos/alextrafford/233711798/ :-) - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ You gotta know when to hold 'em, know when to fold 'em, know when to walk away, and know when to run. - Kenny Rogers, The Gambler ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
On Mon, 2006-09-04 at 13:36 +0100, Bastien Nocera wrote: On Mon, 2006-09-04 at 11:50 +0100, Emmanuele Bassi wrote: Forgot to Cc: some people On Mon, 2006-09-04 at 11:13 +0100, Emmanuele Bassi wrote: Hi all; I've just branched gnome-utils for the stable cycle. The branch is called gnome-2-16; all new development will happen on HEAD. Plans for the 2.17/2.18 cycle (many recycled from the 2.15/2.16 cycle): snip * Switch Screenshot to a full GtkFileChooser dialog and provide the UI it as a shared library for other applications to use; snip Do you have an opened bug for that one? I regularly receive make the Totem screenshot window look like the GNOME one bugs, usually after I've released Totem for a particular version, and would like to CC: myself on it. Sure: http://bugzilla.gnome.org/show_bug.cgi?id=325708 Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
On Mon, 2006-09-04 at 12:22 +0100, Emmanuele Bassi wrote: Hi Jeff; On Mon, 2006-09-04 at 21:01 +1000, Jeff Waugh wrote: quote who=Emmanuele Bassi At the moment, it is fairly difficult to do a window selection unless you know the secret password (key combo or CLI parameters). An optional two step process (made optional by defaulting to full screen as it works now) would help with that. The problem is that I really don't know how to make the Screenshot utility work with a two-step flow without having people screaming at my doorstep because I disrupted their one-step flow. :-) And I quite agree with them: taking a shot of the screen should require the least possible iterations, especially if you want to take loads of shots. I've outlined a proposal for this at least twice, but I can't find the original emails, so I'll do it again. When you call up the screenshot utility from the Applications menu, it should bring up a dialog asking you what you want to do. The dialog would look something like this: || | ( ) Take screenshot of entire screen. | | * Use PrntScrn to do this at any time. | || | ( ) Take screenshot of a single window.| | * Use Alt+PrntScrn to do this at any time. | || | [Cancel] [Shoot] | || When you call the screenshot utility with PrntScrn or Alt+PrntScrn, it does exactly what it does now, because that's exactly what it should do, because it's really useful. People who want a one-step workflow should be (and probably are) using the global keyboard shortcuts. We aren't interfering with them at all. Pros: People who don't know the keyboard shortcuts can still take both fullscreen and window screenshots using this tool. People who don't know the keyboard shortcuts can actually learn the keyboard shortcuts from this dialog. More advanced screenshot modes can be supported, like rectangular selections, without getting in people's way or requiring more keybindings. Cons: I'm sure people on this list will find plenty. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-utils branched for GNOME 2.16
On Mon, 2006-09-04 at 13:17 -0500, Shaun McCance wrote: || | ( ) Take screenshot of entire screen. | | * Use PrntScrn to do this at any time. | || | ( ) Take screenshot of a single window.| | * Use Alt+PrntScrn to do this at any time. | || | [Cancel] [Shoot] | || When you call the screenshot utility with PrntScrn or Alt+PrntScrn, it does exactly what it does now, because that's exactly what it should do, because it's really useful. This is a really good idea. I think we should go for something pretty close to the gimp screenshot dialog (as i've said before) but tweaked slightly to allow us to enclose the text explaining the keyboard shortcuts. This will resolve the problem that people might not know about the shortcuts. I also think including support for allowing timing is also pretty useful. Rob -- Rob Bradford [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
