Announcement

Collapse
No announcement yet.

GNOME's GTK Gets Gtef'ed

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Gapil301 View Post
    Then just give a warning telling the user that the file is huge, instead of blocking him of opening the file. Anyway, what should i expect from the gnome world, after 6 years of gnome 3 development can't even make a desktop that is usable without 2-3 extensions.
    The problem is NOT related to the filesize, it's that gtksourceview is problematic when a file has very long lines. Maybe before quickly jumping at every opportunity to complain, spend some time to actually read up on the actual problem, kthanksbye.

    Comment


    • #12
      Originally posted by bkor View Post

      So if you know loading the file locks up the app, the obvious solution according to you would be to still load the file in readonly mode? Because hey, surely this time it shouldn't lock up right?

      Your suggestion is plainly insane. Thankfully the developers know better than listening to people who have no fucking clue.
      Leaving aside the fact that I just told of a solution that works and you go full retard and tell me it doesn't, let me explain you why it works.
      Because in read-only mode you only have to render the text, you don't have to parse it, provide syntax checking, autocomplete, buffers and such.

      Loading large files won't lock up an application anyway, it will only slow it down.

      Comment


      • #13
        Originally posted by bug77 View Post

        Not in the GTK world. It's a very Apple-like world.
        That's a praise Apple does not deserve.

        Comment


        • #14
          Originally posted by bachchain View Post
          Maybe I'm missing something, but why? Are text editor really so complicated that it's worth making an entire framework for them?
          OMG, yes. We're not just talking about plain text here, but rich stylized text, smart text (program source code) with error checking and auto-completion, bracket indentation, etc. etc. etc...

          Text editing is so ubiquitous, and yet too many applications reinvent the same wheel over and over again. Shared code is the right way to go: GNOME and other toolkits have powerful text editing widgets handling the visuals, but it's nice to see GNOME including a broader framework.

          Comment


          • #15
            But the Text widget should handle that. Why is a premade GtkApplication needed? Oo

            Comment


            • #16
              Originally posted by bkor View Post
              So if you know loading the file locks up the app, the obvious solution according to you would be to still load the file in readonly mode? Because hey, surely this time it shouldn't lock up right?

              Your suggestion is plainly insane. Thankfully the developers know better than listening to people who have no fucking clue.
              Ah damn, now that you told me I'm sure that Kwrite (or any KDE-based editor using the same framework anyway, like say Kate) should have just locked up all times I opened binaries with it by mistake, instead of just showing read-only nonsense text.

              Also the times I used this feature to extract some stuff from corrupted files or still have a look at some special text files.

              Yeah, it's totally wrong, and it shouldn't have happened because it's plainly insane.

              Comment


              • #17
                Originally posted by bachchain View Post
                Maybe I'm missing something, but why? Are text editor really so complicated that it's worth making an entire framework for them?
                They are basically following what KDE did years ago. Kwrite (low-end text editor in KDE) is using the same text editor component also used in Kate (which is a more IDE-like program with integrated console too, which is the same console component you find in Konsole application, btw), KTextEditor.

                The reason is convenience, the framework allows easy integration of a pre-made "text editor that does not suck" in your application.

                Here "text editor that does not suck" means something like Notepad++ or Kwrite or Geany, with syntax highlighting, autocomplete, code folding, and various other IDE-like features.

                Comment


                • #18
                  What are you all talking about? Refusing to load long lines is a feature. And that is in GTK, so the app developers will probably be able to disable that feature or enable it. Also as Sebastien said "and possibly ask to split the line, and detect binary files." . So, it is a feature!

                  Comment


                  • #19
                    Originally posted by starshipeleven View Post
                    They are basically following what KDE did years ago. Kwrite (low-end text editor in KDE) is using the same text editor component also used in Kate (which is a more IDE-like program with integrated console too, which is the same console component you find in Konsole application, btw), KTextEditor.
                    KDevelop is using the same text editor component as well, but adds even more IDE features.

                    Comment


                    • #20
                      Originally posted by starshipeleven View Post
                      ... should have just locked up all times I opened binaries with it by mistake, instead of just showing read-only nonsense text.
                      I have deliberately opened executable binary files in Emacs, made changes to them, and had them still work.

                      Comment

                      Working...
                      X