Idea: Modify main Open/Save fileSelect module to use Nemo's navigation child modules.

[Scott1265]

Hi. Kudos to a great desktop team!

Maybe this idea is already planned, but I didn't see it. A good way to understand my idea is by doing a little self-demonstration. I've also attached 2 reference images below. (I'm using maya with 2.0.14 backported)

On the desktop, left-click and "change desktop background." You get a nice selection in Petra. But what I want isn't here, so: Add (I'm not a Glade Python programmer, and I don't know the module names, so bear with me) You are now in some kind of selectFile Gtk program module, true?

I assume this is a common core function/program module where the title and certain initialization variables are set depending on it's usage / calling function...

Any, here's my question: why doesn't this module use Nemo's child modules for navigation and functionality?

To see what I mean, Open Nemo, and do the following from the Menubar "View" pulldown:

Main Toolbar: off Statusbar: on List Menubar: off

Now, arrange Nemo and the "Add wallpapers" selectFile Window side-by-side on the workspace, make them about the same size so you can compare them. (I moved Firefox to another workspace to make it easier to view.

Now do this: Navigate to the same folder that has image files in both Nemo and the "Add wallpapers" window, and select an image. With the "Add wallpapers", the icons are so tiny I can't tell what the image is I'm selecting, but in Nemo, I can hit CTRL+1 and get large icons that can even be resized.

Is there some reason that the "Add wallpapers" Window program module (actually Cinnamon's core selectFiles Window module) isn't using ALL of Nemo's navigation modules: Tree View, the Main Toolbar (with Location), all of the Hot keys.. (CTRL+1, 2, 3)? It would unify the look and functionality, reduce code, (IMO) add flexibility, and make Mint's main selectFile module upgrade with every upgrade of Nemo, yes?

I also note that some of the fileSelection Windows have a preview image, (look at Launcher's "Select Custom Icon" Window) actually, this fileSelection Window is BETTER than the "Add wallpapers" fileSelection, because Launcher's has an image preview:

IMHO, all of these should be "merged" together, (maybe even into Nemo itself, with different initializations for different situations) and all would benefit from it. e.g., I like the bookmarking functionality of the fileSelection Window better than Nemo's (you don't have to be in the directory / folder to bookmark it, just hit + when it's highlighted. It's faster when bookmarking multiple folders. Also, having a 'recently used' option in Nemo and an image preview when in List mode could also be nice.

One last little thing that's a separate issue, but easy to see in this message: refer back to the first attached image, and notice the .png icon, that's a screen capture that the 'thumbnail-factory' (or whatever it is) didn't convert. In fact, the only way I've found so far to make that a thumbnail is to use gThumb (because it creates thumbnails in ~/.thumbnails) _Which is a whole other major issue with me as well, btw, but I won't get into it here._

I'll write those two up as separate issues if necessary.

btw, Merry Christmas and Happy New Year to the whole team, and keep up the good work!

Scott S

Let me know what you think.

[gauravjuvekar]

Gtk 2 and Gtk 3 have different file-chooser widgets

[Scott1265]

So? Does that mean you can't over-write and unify them?

And I have Cinnamon 2.0.14 Petra running on a Vbox and the file selector widgets look the same.

On Wed, Dec 25, 2013 at 11:55 PM, Gaurav Juvekar notifications@github.comwrote:

Gtk 2 and Gtk 3 have different file-chooser widgets

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31211344 .

[Scott1265]

And too, I should add, that the only reason I didn't actually use my VirtualBox Petra addition is because Vbox's "Take a Sreenshot" gave me a black .png when running Petra. (I have the latest version of Vbox and it will screenshot XP or whatever else) and, even running Gimp inside Petra wouldn't take a screenshot.

So I had to resort to using my Maya backport to get images.

But, like I said, I don't see any difference in look or functionality between the widgets.

Just replace the modules for navigation in the GTK select widget with Nemo's nav modules.

Like I said, I may be unfamiliar with Python GTK GLade syntax API, but not with OOP programming.

On Thu, Dec 26, 2013 at 11:44 AM, Scott S scotta1265@gmail.com wrote:

So? Does that mean you can't over-write and unify them?

And I have Cinnamon 2.0.14 Petra running on a Vbox and the file selector widgets look the same.

On Wed, Dec 25, 2013 at 11:55 PM, Gaurav Juvekar <notifications@github.com

wrote:

Gtk 2 and Gtk 3 have different file-chooser widgets

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31211344 .

[Scott1265]

If I knew the languages I'd just do it myself... I kind of figured I have to anyway, to be honest. But if anyone here would like to point me in the right direction or recommend a "speed course" to transition from other languages to Python GTK Glade etc. : I'm all ears, because I would like to help the project.

Thanks.

On Thu, Dec 26, 2013 at 11:58 AM, Scott S scotta1265@gmail.com wrote:

And too, I should add, that the only reason I didn't actually use my VirtualBox Petra addition is because Vbox's "Take a Sreenshot" gave me a black .png when running Petra. (I have the latest version of Vbox and it will screenshot XP or whatever else) and, even running Gimp inside Petra wouldn't take a screenshot.

So I had to resort to using my Maya backport to get images.

But, like I said, I don't see any difference in look or functionality between the widgets.

Just replace the modules for navigation in the GTK select widget with Nemo's nav modules.

Like I said, I may be unfamiliar with Python GTK GLade syntax API, but not with OOP programming.

On Thu, Dec 26, 2013 at 11:44 AM, Scott S scotta1265@gmail.com wrote:

So? Does that mean you can't over-write and unify them?

And I have Cinnamon 2.0.14 Petra running on a Vbox and the file selector widgets look the same.

On Wed, Dec 25, 2013 at 11:55 PM, Gaurav Juvekar < notifications@github.com> wrote:

Gtk 2 and Gtk 3 have different file-chooser widgets

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31211344 .

[gauravjuvekar]

Any, here's my question: why doesn't this module use Nemo's child modules for navigation and functionality?

What exactly do you mean by Nemo's child modules? All programs use the GtkFileChooserDialog

We have different themes for gtk2 and gtk3 programs but we make them look as similar as possible.

There are minor differences like different "recent" icon , slightly different scroll bar shades, separator dots in lists

BTW that isn't the default mint-x theme.

In glade

In glade-gtk2

recommend a "speed course" to transition from other languages to Python GTK Glade etc.

https://python-gtk-3-tutorial.readthedocs.org/en/latest/index.html

[Scott1265]

What exactly do you mean by Nemo's child modules?

If you refer to the first pic I posted, I changed Nemo to look almost Identical to the GtkFileChooserDialog.

A 'child module' (in both) would be the window with the directory structure, (as a module under Main in both) and the file selection list.

Both the GTK and Nemo have these elements. I assumed this is OOP and, as long as both modules have the same syntax, number of arguments and data types and return the same data type to the caller (function, method whatever), they can be swapped, 1 for 1.

(Should be able to)

However, I've investigated further, and it looks like that what you say about 'All programs use the GtkFileChooserDialog' means that that widget is a lower level GTK widget, that will give it's Inheritance in Glade, gtkmm or whatever, but you can't actually 'replace' a module in it unless you edit the GTK+ source code for the FileChooserDialog. (not going to happen, I don't think, even though it is possible to do. I downloaded GTK's source code packages and damned if I know where to even begin to look for it..LOL)

(This is the old developer's dilemma, programmer's problem: helped and hurt by his/her development environment.)

The solution then becomes, (if this is possible) to write a new FileChooserDialog that accepts all the same arguments syntax etc. exactly like GtkFile... and returns the exact info, (probably just a URI string or something) to the caller... the new widget has to be a 1 for 1 swap, and then Name it: GtkFileChooserDialog. Now I don't know if GTK will allow an overwrite of one of it's own widgets... (it can be done...but... not sure if it's advisable unless GTK allows for it) that way, every program will now use the new updated FileChooserDialog.

I hope this makes sense...

We have different themes for gtk2 and gtk3 programs but we make them look as similar as possible.

In glade [Uploading -Unsaved 1_076.png . . .]()

In glade-gtk2 [Uploading -Unsaved 1_077.png . . .]()

Thanks, but the pics never made it in my e-mail. :(

Have to check them out later in the forum I guess (?) Don't know exactly how this is supposed to work yet... :) please bear with my ignorance until I get up to speed.. (that could be a long time) Hahaha...

I would point out however, that my second screen shot is using 2 GTK dialogs from the new Cinn. backport, and the select for the background wallpapers doesn't show a preview image, but the launcher 'select icon' will, those are both new... and the older Cinnamon from Maya 13 will select background will show an image, because I'm on that right now:

https://mail.google.com/mail/?ui=2&ik=fe452a15b2&view=att&th=143343f76b58910d&attid=0.1&disp=safe&realattid=f_hpph9jn70&zw Screenshot from 2013-12-27 08:29:20.pnghttps://mail.google.com/mail/?ui=2&ik=fe452a15b2&view=att&th=143343f76b58910d&attid=0.1&disp=safe&realattid=f_hpph9jn70&zw (873K) https://mail.google.com/mail/?ui=2&ik=fe452a15b2&view=att&th=143343f76b58910d&attid=0.1&disp=safe&realattid=f_hpph9jn70&zw

IMHO, that's a better GtkFileChooserDialog. And I know the new Cinnamon has 2 different kinds, because you can see them in the second pic I posted in my original post.

I hope this clears things up. :)

Thanks for the link to python-gtk3 tutorial.

Much appreciated.

Scott

On Thu, Dec 26, 2013 at 2:09 PM, Gaurav Juvekar notifications@github.comwrote:

Any, here's my question: why doesn't this module use Nemo's child modules for navigation and functionality?

What exactly do you mean by Nemo's child modules? All programs use the GtkFileChooserDialog

We have different themes for gtk2 and gtk3 programs but we make them look as similar as possible.

In glade [Uploading -Unsaved 1_076.png . . .]()

In glade-gtk2 [Uploading -Unsaved 1_077.png . . .]()

recommend a "speed course" to transition from other languages to Python GTK Glade etc. https://python-gtk-3-tutorial.readthedocs.org/en/latest/index.html

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31231769 .

[Scott1265]

Or, if you could make a copy of the GtkFileChooser widget and edit it, then replace the original that way somehow; that would also work. If it's possible to edit that widget... or you could just directly edit the widget, once you knew exactly what code had to be changed... it all depends on if GTK allows for modifying it's own widgets... lol

I hope this is making some sense...

On Fri, Dec 27, 2013 at 8:35 AM, Scott S scotta1265@gmail.com wrote:

What exactly do you mean by Nemo's child modules?

If you refer to the first pic I posted, I changed Nemo to look almost Identical to the GtkFileChooserDialog.

A 'child module' (in both) would be the window with the directory structure, (as a module under Main in both) and the file selection list.

Both the GTK and Nemo have these elements. I assumed this is OOP and, as long as both modules have the same syntax, number of arguments and data types and return the same data type to the caller (function, method whatever), they can be swapped, 1 for 1.

(Should be able to)

However, I've investigated further, and it looks like that what you say about 'All programs use the GtkFileChooserDialog' means that that widget is a lower level GTK widget, that will give it's Inheritance in Glade, gtkmm or whatever, but you can't actually 'replace' a module in it unless you edit the GTK+ source code for the FileChooserDialog. (not going to happen, I don't think, even though it is possible to do. I downloaded GTK's source code packages and damned if I know where to even begin to look for it..LOL)

(This is the old developer's dilemma, programmer's problem: helped and hurt by his/her development environment.)

The solution then becomes, (if this is possible) to write a new FileChooserDialog that accepts all the same arguments syntax etc. exactly like GtkFile... and returns the exact info, (probably just a URI string or something) to the caller... the new widget has to be a 1 for 1 swap, and then Name it: GtkFileChooserDialog. Now I don't know if GTK will allow an overwrite of one of it's own widgets... (it can be done...but... not sure if it's advisable unless GTK allows for it) that way, every program will now use the new updated FileChooserDialog.

I hope this makes sense...

We have different themes for gtk2 and gtk3 programs but we make them look as similar as possible.

In glade [Uploading -Unsaved 1_076.png . . .]()

In glade-gtk2 [Uploading -Unsaved 1_077.png . . .]()

Thanks, but the pics never made it in my e-mail. :(

Have to check them out later in the forum I guess (?) Don't know exactly how this is supposed to work yet... :) please bear with my ignorance until I get up to speed.. (that could be a long time) Hahaha...

I would point out however, that my second screen shot is using 2 GTK dialogs from the new Cinn. backport, and the select for the background wallpapers doesn't show a preview image, but the launcher 'select icon' will, those are both new... and the older Cinnamon from Maya 13 will select background will show an image, because I'm on that right now:

https://mail.google.com/mail/?ui=2&ik=fe452a15b2&view=att&th=143343f76b58910d&attid=0.1&disp=safe&realattid=f_hpph9jn70&zw Screenshot from 2013-12-27 08:29:20.pnghttps://mail.google.com/mail/?ui=2&ik=fe452a15b2&view=att&th=143343f76b58910d&attid=0.1&disp=safe&realattid=f_hpph9jn70&zw (873K) https://mail.google.com/mail/?ui=2&ik=fe452a15b2&view=att&th=143343f76b58910d&attid=0.1&disp=safe&realattid=f_hpph9jn70&zw

IMHO, that's a better GtkFileChooserDialog. And I know the new Cinnamon has 2 different kinds, because you can see them in the second pic I posted in my original post.

I hope this clears things up. :)

Thanks for the link to python-gtk3 tutorial.

Much appreciated.

Scott

On Thu, Dec 26, 2013 at 2:09 PM, Gaurav Juvekar notifications@github.comwrote:

Any, here's my question: why doesn't this module use Nemo's child modules for navigation and functionality?

What exactly do you mean by Nemo's child modules? All programs use the GtkFileChooserDialog

We have different themes for gtk2 and gtk3 programs but we make them look as similar as possible.

In glade [Uploading -Unsaved 1_076.png . . .]()

In glade-gtk2 [Uploading -Unsaved 1_077.png . . .]()

recommend a "speed course" to transition from other languages to Python GTK Glade etc. https://python-gtk-3-tutorial.readthedocs.org/en/latest/index.html

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31231769 .

[Scott1265]

And even if it could be done, the next problem would be, how to "patch" that into a new GTK update... because, if it was done right, what would happen is, the GtkFileChooser would revert back, and all of the improvements would be lost... so there'd have to be a Mint 1 or 2 update "patch" that would then restore that widget into GTK... (probably not possible, unless you can make a patch for GTK... because if so, that becomes another solution)

:)

On Fri, Dec 27, 2013 at 9:20 AM, Scott S scotta1265@gmail.com wrote:

Or, if you could make a copy of the GtkFileChooser widget and edit it, then replace the original that way somehow; that would also work. If it's possible to edit that widget... or you could just directly edit the widget, once you knew exactly what code had to be changed... it all depends on if GTK allows for modifying it's own widgets... lol

I hope this is making some sense...

On Fri, Dec 27, 2013 at 8:35 AM, Scott S scotta1265@gmail.com wrote:

What exactly do you mean by Nemo's child modules?

If you refer to the first pic I posted, I changed Nemo to look almost Identical to the GtkFileChooserDialog.

A 'child module' (in both) would be the window with the directory structure, (as a module under Main in both) and the file selection list.

Both the GTK and Nemo have these elements. I assumed this is OOP and, as long as both modules have the same syntax, number of arguments and data types and return the same data type to the caller (function, method whatever), they can be swapped, 1 for 1.

(Should be able to)

However, I've investigated further, and it looks like that what you say about 'All programs use the GtkFileChooserDialog' means that that widget is a lower level GTK widget, that will give it's Inheritance in Glade, gtkmm or whatever, but you can't actually 'replace' a module in it unless you edit the GTK+ source code for the FileChooserDialog. (not going to happen, I don't think, even though it is possible to do. I downloaded GTK's source code packages and damned if I know where to even begin to look for it..LOL)

(This is the old developer's dilemma, programmer's problem: helped and hurt by his/her development environment.)

The solution then becomes, (if this is possible) to write a new FileChooserDialog that accepts all the same arguments syntax etc. exactly like GtkFile... and returns the exact info, (probably just a URI string or something) to the caller... the new widget has to be a 1 for 1 swap, and then Name it: GtkFileChooserDialog. Now I don't know if GTK will allow an overwrite of one of it's own widgets... (it can be done...but... not sure if it's advisable unless GTK allows for it) that way, every program will now use the new updated FileChooserDialog.

I hope this makes sense...

We have different themes for gtk2 and gtk3 programs but we make them look as similar as possible.

In glade [Uploading -Unsaved 1_076.png . . .]()

In glade-gtk2 [Uploading -Unsaved 1_077.png . . .]()

Thanks, but the pics never made it in my e-mail. :(

Have to check them out later in the forum I guess (?) Don't know exactly how this is supposed to work yet... :) please bear with my ignorance until I get up to speed.. (that could be a long time) Hahaha...

I would point out however, that my second screen shot is using 2 GTK dialogs from the new Cinn. backport, and the select for the background wallpapers doesn't show a preview image, but the launcher 'select icon' will, those are both new... and the older Cinnamon from Maya 13 will select background will show an image, because I'm on that right now:

https://mail.google.com/mail/?ui=2&ik=fe452a15b2&view=att&th=143343f76b58910d&attid=0.1&disp=safe&realattid=f_hpph9jn70&zw Screenshot from 2013-12-27 08:29:20.pnghttps://mail.google.com/mail/?ui=2&ik=fe452a15b2&view=att&th=143343f76b58910d&attid=0.1&disp=safe&realattid=f_hpph9jn70&zw (873K) https://mail.google.com/mail/?ui=2&ik=fe452a15b2&view=att&th=143343f76b58910d&attid=0.1&disp=safe&realattid=f_hpph9jn70&zw

IMHO, that's a better GtkFileChooserDialog. And I know the new Cinnamon has 2 different kinds, because you can see them in the second pic I posted in my original post.

I hope this clears things up. :)

Thanks for the link to python-gtk3 tutorial.

Much appreciated.

Scott

On Thu, Dec 26, 2013 at 2:09 PM, Gaurav Juvekar <notifications@github.com

wrote:

Any, here's my question: why doesn't this module use Nemo's child modules for navigation and functionality?

What exactly do you mean by Nemo's child modules? All programs use the GtkFileChooserDialog

We have different themes for gtk2 and gtk3 programs but we make them look as similar as possible.

In glade [Uploading -Unsaved 1_076.png . . .]()

In glade-gtk2 [Uploading -Unsaved 1_077.png . . .]()

recommend a "speed course" to transition from other languages to Python GTK Glade etc. https://python-gtk-3-tutorial.readthedocs.org/en/latest/index.html

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31231769 .

[Scott1265]

As a matter of fact, if I knew how to do it, (which I don't) I'd develop some kind of GTK Patch Technology, then I'd guard it like a hawk..lol.

My background is in Computer Aided Design / Engineering 3D Vector Graphics Programming and Solid Modeling, so I doubt if there's any real 1-to-1 comparison, except OOP basics and programming fundamentals... (C++, but the API Jargon etc. is a totally different universe)

On Fri, Dec 27, 2013 at 9:32 AM, Scott S scotta1265@gmail.com wrote:

On the other hand though, if you could actually do that, (write GTK "patches") you could rapidly update and improve Mint beyond the "limitations" of GTK... every program that ran on Mint would benefit from it, but those improvements would only be available on Mint, no where else.

On Fri, Dec 27, 2013 at 9:26 AM, Scott S scotta1265@gmail.com wrote:

And even if it could be done, the next problem would be, how to "patch" that into a new GTK update... because, if it was done right, what would happen is, the GtkFileChooser would revert back, and all of the improvements would be lost... so there'd have to be a Mint 1 or 2 update "patch" that would then restore that widget into GTK... (probably not possible, unless you can make a patch for GTK... because if so, that becomes another solution)

:)

On Fri, Dec 27, 2013 at 9:20 AM, Scott S scotta1265@gmail.com wrote:

Or, if you could make a copy of the GtkFileChooser widget and edit it, then replace the original that way somehow; that would also work. If it's possible to edit that widget... or you could just directly edit the widget, once you knew exactly what code had to be changed... it all depends on if GTK allows for modifying it's own widgets... lol

I hope this is making some sense...

On Fri, Dec 27, 2013 at 8:35 AM, Scott S scotta1265@gmail.com wrote:

What exactly do you mean by Nemo's child modules?

If you refer to the first pic I posted, I changed Nemo to look almost Identical to the GtkFileChooserDialog.

A 'child module' (in both) would be the window with the directory structure, (as a module under Main in both) and the file selection list.

Both the GTK and Nemo have these elements. I assumed this is OOP and, as long as both modules have the same syntax, number of arguments and data types and return the same data type to the caller (function, method whatever), they can be swapped, 1 for 1.

(Should be able to)

However, I've investigated further, and it looks like that what you say about 'All programs use the GtkFileChooserDialog' means that that widget is a lower level GTK widget, that will give it's Inheritance in Glade, gtkmm or whatever, but you can't actually 'replace' a module in it unless you edit the GTK+ source code for the FileChooserDialog. (not going to happen, I don't think, even though it is possible to do. I downloaded GTK's source code packages and damned if I know where to even begin to look for it..LOL)

(This is the old developer's dilemma, programmer's problem: helped and hurt by his/her development environment.)

The solution then becomes, (if this is possible) to write a new FileChooserDialog that accepts all the same arguments syntax etc. exactly like GtkFile... and returns the exact info, (probably just a URI string or something) to the caller... the new widget has to be a 1 for 1 swap, and then Name it: GtkFileChooserDialog. Now I don't know if GTK will allow an overwrite of one of it's own widgets... (it can be done...but... not sure if it's advisable unless GTK allows for it) that way, every program will now use the new updated FileChooserDialog.

I hope this makes sense...

We have different themes for gtk2 and gtk3 programs but we make them look as similar as possible.

In glade [Uploading -Unsaved 1_076.png . . .]()

In glade-gtk2 [Uploading -Unsaved 1_077.png . . .]()

Thanks, but the pics never made it in my e-mail. :(

Have to check them out later in the forum I guess (?) Don't know exactly how this is supposed to work yet... :) please bear with my ignorance until I get up to speed.. (that could be a long time) Hahaha...

I would point out however, that my second screen shot is using 2 GTK dialogs from the new Cinn. backport, and the select for the background wallpapers doesn't show a preview image, but the launcher 'select icon' will, those are both new... and the older Cinnamon from Maya 13 will select background will show an image, because I'm on that right now:

https://mail.google.com/mail/?ui=2&ik=fe452a15b2&view=att&th=143343f76b58910d&attid=0.1&disp=safe&realattid=f_hpph9jn70&zw Screenshot from 2013-12-27 08:29:20.pnghttps://mail.google.com/mail/?ui=2&ik=fe452a15b2&view=att&th=143343f76b58910d&attid=0.1&disp=safe&realattid=f_hpph9jn70&zw (873K) https://mail.google.com/mail/?ui=2&ik=fe452a15b2&view=att&th=143343f76b58910d&attid=0.1&disp=safe&realattid=f_hpph9jn70&zw

IMHO, that's a better GtkFileChooserDialog. And I know the new Cinnamon has 2 different kinds, because you can see them in the second pic I posted in my original post.

I hope this clears things up. :)

Thanks for the link to python-gtk3 tutorial.

Much appreciated.

Scott

On Thu, Dec 26, 2013 at 2:09 PM, Gaurav Juvekar < notifications@github.com> wrote:

Any, here's my question: why doesn't this module use Nemo's child modules for navigation and functionality?

What exactly do you mean by Nemo's child modules? All programs use the GtkFileChooserDialog

We have different themes for gtk2 and gtk3 programs but we make them look as similar as possible.

In glade [Uploading -Unsaved 1_076.png . . .]()

In glade-gtk2 [Uploading -Unsaved 1_077.png . . .]()

recommend a "speed course" to transition from other languages to Python GTK Glade etc. https://python-gtk-3-tutorial.readthedocs.org/en/latest/index.html

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31231769 .

[gauravjuvekar]

I think we missed an important point-WHY do you want to do this? Changing backgrounds is not a very frequent activity (i hope) that you can't do with the list of files. For all other uses other than changing backgrounds, this isn't a cinnamon issue. It would be better to take it up with gnome. Also, nemo isn't exactly lean enough on resources to justify opening it everytime you want to select a file.

[Scott1265]

It was just an example of one of the uses of the file select dialog where not having an image (or that option) made things difficult. That same dialog, like you said earlier, is used throughout, and there are other instances where having more functionality / flexibility in file selection is a good thing.

But you're right: it's more of an issue for gnome, since it's their widget.

So go ahead and delete the post.

I can always view the backgrounds in gThumb and copy and paste the filename from there into the file select dialog, instead of actually having it show me an image thumbnail right in the dialog, (Like the earlier version of Cinn. did) like the Launcher 'Select Icon Dialog' does. Selecting your own custom user background in Cinn. 2.0 is now a partial downgrade from earlier. 2 steps forward, 1 step back.

Same with if I'm trying to upload an image. I can just (if I'm lucky and it pops the right fileselect dialog this time, click down through a long list of files and look at the image preview until I finally get to the one I want; or just use gThumb to find the one I want and then cut-and-paste the image URI into the file chooser dialog.

In the mean time the Windo$ dude has already uploaded 5 pics... while I use a magnifying glass trying to see the image I'm looking at.

But yeah, I'll take it up with gnome; it's their baby.

Like I said, I figured I'd have to do it myself.

Thanks.

On Fri, Dec 27, 2013 at 1:27 PM, Gaurav Juvekar notifications@github.comwrote:

I think we missed an important point-WHY do you want to do this? Changing backgrounds is not a very frequent activity (i hope) that you can't do with the list of files. For all other uses other than changing backgrounds, this isn't a cinnamon issue. It would be better to take it up with gnome. Also, nemo isn't exactly lean enough on resources to justify opening it everytime you want to select a file.

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31274017 .

[gauravjuvekar]

Ok, it's not gnome's problem, they do provide an option to add a preview widget.

http://lazka.github.io/pgi-docs/api/Gtk_3.0/interfaces/FileChooser.html#Gtk.FileChooser.set_preview_widget http://python-gtk-3-tutorial.readthedocs.org/en/latest/dialogs.html#filechooserdialog

GtkFileChooserDialog can call GtkFileChooser 's functions (examples in C)

https://developer.gnome.org/gtk3/3.2/GtkFileChooserDialog.html https://developer.gnome.org/gtk3/3.2/GtkFileChooser.html#GtkFileChooser--preview-widget

I opened a new issue #2781 You can close this one.

I can always view the backgrounds in gThumb and copy and paste the filename from there into the file select dialog,

Or you could right click the image in nemo and use set as wallpaper.

[Scott1265]

But again, pardon me, selecting backgrounds / setting wallpaper's isn't the point.

I just used it as an example of the main issue.

If you want to compete with Mico$oft Windo$, (which I assume is a goal) then, IMO, you have to look at what M$-Win does well, and at least offer it in some easy way to the migrants.

And what I've been trying to drive home here is something they've had the ability to do since XP: show thumbnails in the file selection dialog.

But this brings up another issue: how Mint (gnome?) handles thumbnails.

e.g., right now in Nemo there is an error where it creates thumbnails in ~/.cache/thumbnails, but actually looks for the thumbs in ~/.thumbnails, so new images processed by Nemo will only be an image-type-icon. My work around is to replace ~/.cache/thumbnails with a link to ~/.thumbnails.

I'm not the only one having this issue. That whole process should be looked at. Why putting thumbnails in my $home??

I get a flash stick from a buddy just back from Europe and put it in, look at the pictures in gThumb, and now I have a bunch of thumbnails in my ~/.thumbnails folder from his USB flash drive.

????? Really? Yes. Because I looked.

gThumb creates it's thumbnails in ~/.thumbnails, but Nemo uses ~/.cache/thumbnails... so now I have (or had) 2 places with the same thumbnails.... I have to manage my own thumbnails... yes, I do.

They should be put into a thumbnail .cache or .thumbs file in the same directory, (see the old Windo$ ACDsee.exe program or Irfanview.exe they have (or had) options of caching in a single file, in the same directory as the images, (some did, not 100% those 2 did) or user specified location for the .thumbs cache file.

This could be a related issue, because if thumbnail viewing was added to the GtkFileChooserDialog, where are any new image thumbs going to be cached?

(gnome's default, afaik, is ~/.thumbnails. That's BS, IMO.)

Not sure how to "close" that other issue but I'll get to it when I can.

Thanks for the help and the links.

And just so you know, my only goal is to help Mint become the best OS out there, and bury Windo$, (R.I.Ps U POS)

So my sometimes sarcastic, argumentative, and impatient attitude isn't personal; it's only in furtherance of that stated goal.

Scott

On Sat, Dec 28, 2013 at 1:48 AM, Gaurav Juvekar notifications@github.comwrote:

Ok, it's not gnome's problem, they do provide an option to add a preview widget.

http://lazka.github.io/pgi-docs/api/Gtk_3.0/interfaces/FileChooser.html#Gtk.FileChooser.set_preview_widget

http://python-gtk-3-tutorial.readthedocs.org/en/latest/dialogs.html#filechooserdialog

GtkFileChooserDialog can call GtkFileChooser 's functions (examples in C)

https://developer.gnome.org/gtk3/3.2/GtkFileChooserDialog.html

https://developer.gnome.org/gtk3/3.2/GtkFileChooser.html#GtkFileChooser--preview-widget

I opened a new issue #2781https://github.com/linuxmint/Cinnamon/issues/2781You can close this one.

I can always view the backgrounds in gThumb and copy and paste the filename from there into the file select dialog,

Or you could right click the image in nemo and use set as wallpaper.

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31291763 .

[gauravjuvekar]

I think gnome have a pretty good reason to let each application implement it-images are not the only kinds of files that can be previewed. This way, each app can implement previewing only the filetypes that it supports. eg do you really expect gnome to implement a previewer for .mol files(chemical molecule diagrams)? That's the job of the program that you are using to open that type of file.

[Scott1265]

I see now, but that code is only for that single small preview window on the right side, like the new 'Select Custom Icon' file select icon used by Launcher.

What I'm talking about is having the GtkFileChooserDialog show the whole directory as thumbnails like Nemo/Nuatilus does if you type CTRL+1. (most of Nemo's hot-keys should work in the GtkFileChooserDialog, e.g. CTL+L) If you want to compete with M$-Win XP, (because that was statistically still the most used OS in the world, last time I checked.)

Thus: Nemo's child modules, .method whatever it is, should be put in place of GtkFileChooserDialog's module, .method, function whatever it is, where it displays the files. But both Classes, .methods, functions, instances, aka modules, from Nemo/Nautilus should be added to the GtkFileChooserDialog: a directory tree option on the left, and the file selector on the right.

Again, if you refer to the first pic I posted, the GtkFileChooserDialog should behave / function and look just like the dialog on the right, which is just Nemo with certain view options turned on/off.

As far as using system resources, it wouldn't have to be all of Nemo, just the pertinent "modules" objects, classes, .methods functions et. al. that would have to be used. And they could be loaded-on-demand. e.g., if CTRL+1 is pressed, the "view directory as icons.method would be demand loaded...)

Whatever. I'm out of my element, like I said before. Ask me to design an application within certain CAD software to automatically draw a 3D roof structure on a building, or automatically attach a piston rod to a crank-shaft and show the finite element analysis of the stress points, and I could do that, (or lead a team of people to do it) but ask me to show thumbnails in a file selector dialog, and I'm freggin lost.

:)

On Sat, Dec 28, 2013 at 8:45 AM, Scott S scotta1265@gmail.com wrote:

But again, pardon me, selecting backgrounds / setting wallpaper's isn't the point.

I just used it as an example of the main issue.

If you want to compete with Mico$oft Windo$, (which I assume is a goal) then, IMO, you have to look at what M$-Win does well, and at least offer it in some easy way to the migrants.

And what I've been trying to drive home here is something they've had the ability to do since XP: show thumbnails in the file selection dialog.

But this brings up another issue: how Mint (gnome?) handles thumbnails.

e.g., right now in Nemo there is an error where it creates thumbnails in ~/.cache/thumbnails, but actually looks for the thumbs in ~/.thumbnails, so new images processed by Nemo will only be an image-type-icon. My work around is to replace ~/.cache/thumbnails with a link to ~/.thumbnails.

I'm not the only one having this issue. That whole process should be looked at. Why putting thumbnails in my $home??

I get a flash stick from a buddy just back from Europe and put it in, look at the pictures in gThumb, and now I have a bunch of thumbnails in my ~/.thumbnails folder from his USB flash drive.

????? Really? Yes. Because I looked.

gThumb creates it's thumbnails in ~/.thumbnails, but Nemo uses ~/.cache/thumbnails... so now I have (or had) 2 places with the same thumbnails.... I have to manage my own thumbnails... yes, I do.

They should be put into a thumbnail .cache or .thumbs file in the same directory, (see the old Windo$ ACDsee.exe program or Irfanview.exe they have (or had) options of caching in a single file, in the same directory as the images, (some did, not 100% those 2 did) or user specified location for the .thumbs cache file.

This could be a related issue, because if thumbnail viewing was added to the GtkFileChooserDialog, where are any new image thumbs going to be cached?

(gnome's default, afaik, is ~/.thumbnails. That's BS, IMO.)

Not sure how to "close" that other issue but I'll get to it when I can.

Thanks for the help and the links.

And just so you know, my only goal is to help Mint become the best OS out there, and bury Windo$, (R.I.Ps U POS)

So my sometimes sarcastic, argumentative, and impatient attitude isn't personal; it's only in furtherance of that stated goal.

Scott

On Sat, Dec 28, 2013 at 1:48 AM, Gaurav Juvekar notifications@github.comwrote:

Ok, it's not gnome's problem, they do provide an option to add a preview widget.

http://lazka.github.io/pgi-docs/api/Gtk_3.0/interfaces/FileChooser.html#Gtk.FileChooser.set_preview_widget

http://python-gtk-3-tutorial.readthedocs.org/en/latest/dialogs.html#filechooserdialog

GtkFileChooserDialog can call GtkFileChooser 's functions (examples in C)

https://developer.gnome.org/gtk3/3.2/GtkFileChooserDialog.html

https://developer.gnome.org/gtk3/3.2/GtkFileChooser.html#GtkFileChooser--preview-widget

I opened a new issue #2781https://github.com/linuxmint/Cinnamon/issues/2781You can close this one.

I can always view the backgrounds in gThumb and copy and paste the filename from there into the file select dialog,

Or you could right click the image in nemo and use set as wallpaper.

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31291763 .

[gauravjuvekar]

Oh, hate to disappoint you but this is old-really old

https://bugzilla.gnome.org/show_bug.cgi?id=141154 https://bugs.launchpad.net/gtk/+bug/137606

But gnome devs really should look into this since they are going after the touch-friendly UI.

[Scott1265]

Sigh... of course not. But .jpg, .jpeg .png, and .gif are common and universal image file types, why do you think programs like gThumb even exist?

I guess you don't have 5000+ images on your computer. So you don't understand what I'm talking about, and how could you? Go ahead and accumulate over 5000 pictures at least, and then try to use Mint to upload some picture you know exists somewhere in there.... then maybe you'll get it.

& I'm not surprised it's an old idea!!!! You're not disappointing me-- Gnome is the disappointment. Window's has been doing this since XP, like I said! So, in other words, Gnome has had ppl wanting this for a long time, (probably Windows Migrants) but Gnome has been ignoring them, and hasn't even been trying to keep up with XP's functionality in directories and file selection... no surprise there.

It's not about what a bunch of geeky-programmer types what, and what they understand, and the whys and wherefore's of what a bunch of geeks think should be and for what etc. IT'S ABOUT WHAT THE MAJORITY OF OS USERS IN THE WORLD WANT

So I'm not surprised that the average Windo$ user doesn't stick with Linux, and thinks Linux sucks; and adobe abandons it, and Dell abandons it...it could be the BEST OS ever, but if it can't even do the most basic meat-and-potatoes functionality of XP, things that the majority of OS users in the world have come to EXPECT FROM AN OS; is it any wonder?????

Seriously.... think about it.

So, why should I waste my time taking this tired 'really old' idea to gnome.... again???

Like I said, I figured I'd have to do it myself dude....maybe you just don't get my philosophy, it's really freggin simple:

GIVE THE PEOPLE WHAT THEY WANT. And what they want is what they have COME TO EXPECT from Micro$oft. Period.

Not that everything M$ does should be copied-- OF COURSE NOT!!! But there are some things that people use, that make their lives easier, that they expect: like being able to select a picture from a whole group of thumbnails in a directory (and even resize them) when they want to do simple tasks with images, like: open an image file, save an image file, or upload an image file. (how many people do you think, in today's world, want to be able to upload image files easily from their OS?)

You are being limited by your development environment. (typical) And you have to wait for them to decide when to offer whatever widget they decide you, and the rest of Linux desktop users, basically, need.

Think outside the GTK box. Take control of your own development environment. If Gnome don't or won't offer it, patch it, and offer it yourself. (Have mint do it; have Mint offer things that Gnome won't; things that help Widow$ Migrants get what they expect from an OS, and of course offer everything else that makes Linux at least 10X better than Windo$.

Sorry for the TL;DR rant.

On Sat, Dec 28, 2013 at 11:20 AM, Gaurav Juvekar notifications@github.comwrote:

Oh, hate to disappoint you but this is old-really old

https://bugzilla.gnome.org/show_bug.cgi?id=141154 https://bugs.launchpad.net/gtk/+bug/137606

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31299466 .

[gauravjuvekar]

Go ahead and accumulate over 5000 pictures at least, and then try to use Mint to upload some picture you know exists somewhere in there

That's why we have folders that we can name. And files that we can name. Do you mean to say that you want to use this feature to look through 5000 images to find the one you need?

As for uploading, the firefox upload menu handles this nicely. The feature would be nice but it's not essential.

[dalcde]

However, I've investigated further, and it looks like that what you say about 'All programs use the GtkFileChooserDialog' means that that widget is a lower level GTK widget, that will give it's Inheritance in Glade, gtkmm or whatever, but you can't actually 'replace' a module in it unless you edit the GTK+ source code for the FileChooserDialog. (not going to happen, I don't think, even though it is possible to do. I downloaded GTK's source code packages and damned if I know where to even begin to look for it..LOL)

Exactly

The solution then becomes, (if this is possible) to write a new FileChooserDialog that accepts all the same arguments syntax etc. exactly like GtkFile... and returns the exact info, (probably just a URI string or something) to the caller... the new widget has to be a 1 for 1 swap, and then Name it: GtkFileChooserDialog. Now I don't know if GTK will allow an overwrite of one of it's own widgets... (it can be done...but... not sure if it's advisable unless GTK allows for it) that way, every program will now use the new updated FileChooserDialog.

No you don't do that.

But you're right: it's more of an issue for gnome, since it's their widget.

Closing. No more off-topic discussions please.

[Scott1265]

So you'll never be able to offer the same functionality as users who migrate from XP.

So no more wasting my time with this project then, please.

On Sun, Dec 29, 2013 at 5:07 AM, dalcde notifications@github.com wrote:

However, I've investigated further, and it looks like that what you say about 'All programs use the GtkFileChooserDialog' means that that widget is a lower level GTK widget, that will give it's Inheritance in Glade, gtkmm or whatever, but you can't actually 'replace' a module in it unless you edit the GTK+ source code for the FileChooserDialog. (not going to happen, I don't think, even though it is possible to do. I downloaded GTK's source code packages and damned if I know where to even begin to look for it..LOL)

Exactly

The solution then becomes, (if this is possible) to write a new FileChooserDialog that accepts all the same arguments syntax etc. exactly like GtkFile... and returns the exact info, (probably just a URI string or something) to the caller... the new widget has to be a 1 for 1 swap, and then Name it: GtkFileChooserDialog. Now I don't know if GTK will allow an overwrite of one of it's own widgets... (it can be done...but... not sure if it's advisable unless GTK allows for it) that way, every program will now use the new updated FileChooserDialog.

No you don't do that.

But you're right: it's more of an issue for gnome, since it's their widget.

Closing. No more off-topic discussions please.

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31314447 .

[Scott1265]

to users who migrate....

And this is exactly the attitude and the result I expected.... and why Linux will always be behind. Too bad too, but it won't be my fault.

Like I know: if I want it done right, I have to do it myself.

Case closed.

On Sun, Dec 29, 2013 at 7:13 AM, Scott S scotta1265@gmail.com wrote:

So you'll never be able to offer the same functionality as users who migrate from XP.

So no more wasting my time with this project then, please.

On Sun, Dec 29, 2013 at 5:07 AM, dalcde notifications@github.com wrote:

However, I've investigated further, and it looks like that what you say about 'All programs use the GtkFileChooserDialog' means that that widget is a lower level GTK widget, that will give it's Inheritance in Glade, gtkmm or whatever, but you can't actually 'replace' a module in it unless you edit the GTK+ source code for the FileChooserDialog. (not going to happen, I don't think, even though it is possible to do. I downloaded GTK's source code packages and damned if I know where to even begin to look for it..LOL)

Exactly

The solution then becomes, (if this is possible) to write a new FileChooserDialog that accepts all the same arguments syntax etc. exactly like GtkFile... and returns the exact info, (probably just a URI string or something) to the caller... the new widget has to be a 1 for 1 swap, and then Name it: GtkFileChooserDialog. Now I don't know if GTK will allow an overwrite of one of it's own widgets... (it can be done...but... not sure if it's advisable unless GTK allows for it) that way, every program will now use the new updated FileChooserDialog.

No you don't do that.

But you're right: it's more of an issue for gnome, since it's their widget.

Closing. No more off-topic discussions please.

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31314447 .

[Scott1265]

No, one last thing: please don't ever send me another e-mail like that last one that was a flagrant INSULT TO MY INTELLIGENCE.

On Sun, Dec 29, 2013 at 7:18 AM, Scott S scotta1265@gmail.com wrote:

to users who migrate....

And this is exactly the attitude and the result I expected.... and why Linux will always be behind. Too bad too, but it won't be my fault.

Like I know: if I want it done right, I have to do it myself.

Case closed.

On Sun, Dec 29, 2013 at 7:13 AM, Scott S scotta1265@gmail.com wrote:

So you'll never be able to offer the same functionality as users who migrate from XP.

So no more wasting my time with this project then, please.

On Sun, Dec 29, 2013 at 5:07 AM, dalcde notifications@github.com wrote:

However, I've investigated further, and it looks like that what you say about 'All programs use the GtkFileChooserDialog' means that that widget is a lower level GTK widget, that will give it's Inheritance in Glade, gtkmm or whatever, but you can't actually 'replace' a module in it unless you edit the GTK+ source code for the FileChooserDialog. (not going to happen, I don't think, even though it is possible to do. I downloaded GTK's source code packages and damned if I know where to even begin to look for it..LOL)

Exactly

The solution then becomes, (if this is possible) to write a new FileChooserDialog that accepts all the same arguments syntax etc. exactly like GtkFile... and returns the exact info, (probably just a URI string or something) to the caller... the new widget has to be a 1 for 1 swap, and then Name it: GtkFileChooserDialog. Now I don't know if GTK will allow an overwrite of one of it's own widgets... (it can be done...but... not sure if it's advisable unless GTK allows for it) that way, every program will now use the new updated FileChooserDialog.

No you don't do that.

But you're right: it's more of an issue for gnome, since it's their widget.

Closing. No more off-topic discussions please.

— Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/2775#issuecomment-31314447 .