make edit-able path bar use gtk.entry [$100]

[Danielle Foré]

When the path bar is edit-able it should look like a text entry and not a depressed button.

[Victor Martinez (victored)]

Actually, this should happen on the theme side if we want to keep the code in good shape. Marlin already had it like this in the past and I think it was changed because it felt hacky.

[Danielle Foré (danrabbit)]

Is there any way we can just change the class in the widget from button to entry when it becomes selected like that?

[Mario Guerriero (mefrio-g)]

we can add an hidden entry near the path bar and show it when the path is in the editing mode

[xapantu (xapantu)]

It was changed in marlin because it creates a lot of bugs with most themes (every theme but elementary IIRC). It is not hard to change, you have to add a gtkstylecontext and use it to draw the entry background, see libwidgets/LocationBar.vala.

[Danielle Foré (danrabbit)]

Ah, well if it creates problems in other themes can we just add a class like ".pathbar" or something and then I can do ".patbar:selected" in the theme or something.

[David Gomes (davidgomes)]

What is the progress on this bug? Daniel, any attempts on checking if it's an eGTK bug?

[Danielle Foré (danrabbit)]

David, I can't do anything on my side to force Files to use a class. Either a new class like ".pathbar" needs to be added so I can theme this class or Files needs to request the .entry class for the selected state (which a few people felt was hacky).

[Mario Guerriero (mefrio-g)]

Daniel creating a ".pathbar" class in the theme would be excellent. Let me to know when you will complete it and then I'll fix Files.

[Danielle Foré (danrabbit)]

Okay, this should be committed in eGTK. I did ".pathbar:active" since I only want to catch the active state of the button. It might need tweaking. But this should be fixed in eGTK.

[Vincent (vincent-john-6)]

Would adding a .pathbar class allow for adjusting the padding of the path-bar independently of the other toolbar items?

[Victor Martinez (victored)]

Daniel, do we want pressed breadcrumbs to look like an entry too?

AFAIK ".pathbar:active" makes no distinction between the pressed editable area and every other area where there's an "active" state.

[Danielle Foré (danrabbit)]

Committed a workaround in egtk.

I want to keep this bug open in Files since doing the CSS seems to have exposed that this widget is pretty hacky and probably needs to be redone at some point.

[KJ Lawrence (kjtehprogrammer)]

I think this is pretty much what my editable-pathbar branch does - convert the Gtk.EventBox pathbar widget into a Gtk.Entry widget. I'm still not 100% on how it works with other themes though - not really sure how to test that so it could still be a problem.

[Danielle Foré (danrabbit)]

Renaming this ticket in light of the work that KJ has been doing.

[Danielle Foré (danrabbit)]

Also added $100 to it https://www.bountysource.com/issues/967877-make-edit-able-path-bar-use-gtk-entry

[xapantu (xapantu)]

Hum, I am not sure this was a good move. Well, indeed, it probably solves a few bugs, but feature-wise, the integrated entry was better in my opinion.

It did not show /home/user, which is more user-friendly.
It was better readable, since the directories were clearly separated.
Still some graphical issue here (with adwaita, I'll try with elementary).
There was no glitch when you focused the entry.
And it looked best.

If I put it back (in an ideal world, without bugs), would it be merged, or will it be refused? (I am not that interested in writing a second time some useless code to be honnest ;) ).

[Timo Reimerdes (timorei)]

I don't think that the editable path bar was used by anyone who wouldn't know about /home/username/...

I actually thought this was a great move, as it makes entering the paths so much easier (including copy/paste from notes!)

Yes, the other version looked a bit smoother, but if you have to sacrifice copy-paste between console & filemanager for it to work, I'd stay with the pure text pathbar.