-
Sébastien Wilmet authored
This will be replaced by the previous UI: two buttons, "Open" to open the dialog, and an arrow to open the recent menu. It's a pragmatic decision to simplify the gedit code, because there are not enough developers, and too many bugs. Do you prefer a rock-solid text editor? Or a text editor with some shiny and non-essential features that complexifies the code, at the expense of more bugs? The gedit core should have a much smaller code size, with all the essential features implemented in libraries. The OpenDocumentSelector showed only 5 items, while the normal menu can show more (10 by default). The search inside the popover duplicated the search in the file chooser dialog. To open a file, one search entry is enough, it avoids a possible confusion. The OpenDocumentSelector showed all recent text files, not just those previously opened in gedit. Again, this duplicates the feature present in the file chooser dialog. The new simple menu will show only files previously opened in gedit, which is IMHO more logical. There is also the fact that the OpenDocumentSelector used GtkTreeView. It is planned at some point in the future that GtkTreeView will be removed from GTK. Porting to GtkListBox would be a lot of work. The full file paths will also be visible with the new simple menu, in the statusbar. GeditOpenDocumentSelector was never adopted by other GNOME apps. gedit was the only app with such an open file popover. It takes almost 3000 lines of code to do so. While the simple menu takes less than 100's (in gedit). So the OpenDocumentSelector complicated a lot the code of gedit.
27f54a9a