On Wednesday, 2009-12-09, Draciron Smith wrote: > On Wed, Dec 9, 2009 at 6:36 AM, Kevin Krammer <kevin.krammer@xxxxxx> wrote: > > I'd say it is actually a lot less common than e.g. on Windows. Basically > > every application by one of the big software vendors, including > > Microsoft, is written in C++. > > I'll disagree there. The Linux world missed a HUGE opportunity as the > majority of apps out there are written in VB & the VB# languages. Yes > system level stuff is C++ well sorta. VIsual C++ is almost C++. At > one point it was almost a decent language to write in. The early IDEs > for VC were really nice but M$ of course changed just to change. I know that quite some software is written in VB which is why I specifically wrote "vendors". Products like Micrsoft Office, Adobe Photoshop, etc. are basically all written in C++. VB is huge on in-house or custom built solutions. Unfortunately there is nothing "the Linux world" can do about VB not being available for Linux, the respective vendor does not offer that product and has even discontinued the traditional version for its own platform. There are Basic based development frameworks such as Gambas or RealBasic. The latter being a commercial product running also on Windows and Mac OSX and as far as I know claims to have some kind of VB importer/converter to make changing to it easier, > The thing is VB code is far more portable to Gambas than it is too > .NET. Millions of businesses and third party apps were left in the > lurch in a big way with the .NET migration and were desperate for a > way to keep their codebase. Exactly. > Much of this was middleware servers and > end user level application programming. For example all of the major > middle tier accounting packages for windoze were written in VB or > Delphi. Interesting. I knew that Delphi had a huge following but thought that VB was mostly be used for projects which are not sold (but for all scales) > In the VAR world Delphi reigned supreme. In terms of > shareware a huge percentage of it was written in VB or Delphi. So > it'd made perfect sense to port to Gambas. More reliable servers, more > powerful and secure servers and they got to keep their code base. Not > just keep it, they didn't have to yet again forget everything they > learned and relearn how to program again. Delphi had a Linux version > and Gambas was very close to VB syntax. Well, since there is Gambas and I've heard it is quite a sophisticated framework, doesn't this fulfill the requirements for attracting basic based developers? In masses? > > I guess the difference leading to your point of view is the focus on > > certain languages. > > While Basic and Pascal (Delphi) are the strong ones on Windows, it is be > > Python/Ruby/Perl on Unix/Linux. If you are looking for things written in > > Basic or Pascal on Linux you might come to the wrong conclusion that only > > C/C++ is being used. Much like if you would look for things written in > > Python or Perl on Windows you'd come to a similar conclusion. > > Python and Perl are very popular on Linux and gaining popularity even > among Windoze users. They are two examples I used. Gambas is another > though I think Borland discontinued Kylix and I haven't seen anything > Delphi like to replace it on Linux. Gambas is new and gaining strength > and so is the .NET clone, forget the name off hand. WXBasic also shows > strong promise. Once the IDEs in these languages catch up then the > world opens up to mid level programmers and a whole slew of must have > apps will sprout in Linux. I think Borland gave up on the development tool business, i.e. sold this part of the company to some other firm. If I remember correctly they've made a huge mistake with Kylix when they introduced a new component model instead of using the same one Delphi used. They probably wanted to switch Delphi as well, but just resulted in Kylix being ignored by Delphi based developers. However, I think the FreePascal people have a component model as well, not sure how it compares to Delphi though. I wouldn't call Gambas inew", it has been available for years and seems to have loyal followers and all. But I haven't seen any common application built with it yet so my guess is that it is, quite like VB, mostly used for in-house and custom solutions. > The key though is exposing functionality in KDE, Gnome, GIMP, etc too > these languages. Right now it's hodgepodge. The language itself works > out a way. Perl has developed a rich set of libs to expose > functionality of common libs and apps typically seen on Linux distros > but it's taken years to build all these libs and they often lead to an > intricate dependency hell that inspired CPAN. Python is just now > starting to get access to a great deal of essential functionality. In > the not so distant past a Python programmer often had to reinvent the > wheel any time they wrote anything elaborate in Python. Both KDE and GNOME (as well as frameworks they build on like Qt or GTK+) have had bindings for a number of languages for years, Python being one of the best support ones. I think the printer configuration tool for KDE is written using PyKDE, GNOME land seems to have a few more due to plain C not being that much of an alternative like C++/Qt is. The tools are there, have been for years, but the prognosed huge influx of willing developers has yet to be detected. > > Exactly. Which is why development tools/frameworks such as Gambas exist. > > There is also RealBasic which can be used to create applications running > > on Windows and Mac OSX as well. > > > > However, Basic frameworks seem to have more followers from the group of > > people already using Basic. Nowadays beginners seem to prefer Python. > > Until recently Basic was not well supported on Linux. Probably depends how you define recently, Gambas has had late 1.x releases in 2007 so it is probably around for 3 or 4 years. KBasic is definitely older, I remember being subscribed to is mailinglist in the early 2000 years (probably 2002). > clones but lets face it GWBasic has been obsolete for 20 years. Today > your seeing a large upswing in people in all the supported languages. I mainly see people using Python more, haven't seen any Basic app yet and Ruby seems to be mostly used for server stuff (Ruby on Rails, etc). > I would have loved to have made it a KDE app but I honestly despise > working in C++ for anything but a short app. I'd love to take Kwrite > and use it for the most basic editing features and then add from > there. It'd be perfect for text editing and save me a great deal of > coding in not having to re-invent the wheel. One doesn't have to use C++ to write an application using KDE technologies. There are bindings for several languages, the two most active ones are probably Python and C#. The editor component used by KWrite is also used by other apps (such as Kate or KDevelop) and I am pretty sure it is available in the bindings as well. But that's probably better discussed on the bindings list. > > I've yet to see any developer even considering a fork. So far such > > suggestions seem to come from bloggers and journalists with insufficient > > insight into the task at hand. > > Some of them even suggested stuff like forking KDE 3 era code and porting > > it to Qt4, ignoring the man-years of work that it took the code base > > maintainers to do that. > > I have not looked at what it would take. Haven't even opened KDE > source code in years. Yes it may take years to do but the level of > dissatisfaction with KDE 4 is so great that people are not going to > bite the bullet and put up with the loss of functionality. Most complains I've seen about "loss of functionality" seems to be targetted at the workspace and there again mostly panel and desktop. Yet there hasn't been anyone trying to implement these two comonents differently so I find it highly unlikely that there would be enough developers to actually maintain, even less develop, a full fork. Which is why I usually suggest to try developing and maintaining a Qt4 port of KDesktop and Kicker first, because even that is going to be a lot of work. It's not likey anything would depend on a specific implementation for those items, otherwise applications would run on other workspaces such as GNOME's. > You also forget KDE 4 has done most of the work of porting for QT > already. A huge chunk of the functionality is already ported, quite > possibly all the essential stuff is already done in KDE 4, from there > it might just be a matter of returning functionality and removing > damage like the plasmoids. Another advantage of doing alternative workspace components is that one doesn't have to remove anything. > Should be trivial to revive support for > multiple desktop background images for example. Adding applications > too the panel should not be a huge deal. The QT lib support is already > there, if the code in 3.5 was good code that should be fairly well > insulated or easy to modify based on other KDE 4 functionality. From what I've heard and read one of the reasons a replacement for KDesktop and Kicker was introduced is that the old code was not good code anymore but full of hacks thrown in for all kinds of features over years of development. But I haven't had a look at the code myself, could be exaggerated (though I doubt it). > Again > I preface this with not having looked at the code yet. Something I'd > rather not do as time constraints and working in C++ are two factors. Desktop and panel can be separate applications, one could use any technology available that allows creating processes with a GUI. E.g. (since that came up earlier) Gambas. > > So one could for at a stage where all the porting has happend already, > > something like 4.0 release stage. > > But why would anyone throw away all the things done between then and now? > > Because it tears at everything that made KDE dear to a large number of > people. KDE 4 is NOT KDE except in name. It has betrayed the > principles and ideas that made KDE so successful. Quite overgeneralizing statement. Most of KDE's products is exactly like they used to be, often developed a lot further, e.g. Okular surpassing KPDF by far. > > So if one forks the state of trunk now, why would any exisiting > > developers work on whatever they are working right now just in a > > different repository? I think we can be pretty sure they are not likely > > to work on a different area of the code base because they could to that > > right now as well. > > I think any developers that defect will mostly be %100 defectors. As > far as I know I've not met or talked too any KDE developers. I suspect > some have left the project in protest of what's happened, which might > explain why Kedit is suddenly no longer supported. I think the last developer who left in protest was Neil Stevens (or whatever he was called). Fun thing that :) Kedit was actually maintained for a while after the porting but it seems it became unmaintained again a bit later. Or maybe its development moved to a different source repository. The main point is that as an application developer I would want to continue developing whatever application I am currently working on, not climb down into the trenches of library work or work on totally unrelated apps. I could do that right now as well, or leave the base work to people I know do be capable of doing that. Which is why, again, development of alternative workspace components is a lot more likely to achieve anything, even if it is just reaching enough stability to be of use to the ones developing them. > > Actually an interesting fact about those fork suggestions is that they > > come from the context of people being unsatisfied with the Plasma > > desktop. Interestingly none of those fork suggestors seems to consider > > forking just KDesktop+Kicker. > > That is actually a good suggestion. %95 of KDE is things people do not > see. I'd say the other way around. Sure there are quite some lines of code in kdelibs, but some of the application modules have large numbers of applications, e.g. kdegames, kdeedu, or big ones, e.g. kdepim. > So potentially a fork on Kdesktop is far more logical. Depends on how > difficult it'll be to add back all the lost customization and > functionality. My guess would be that there is no need to "add back" things unless something has been removed during the porting (highly unlikely). Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
Attachment:
signature.asc
Description: This is a digitally signed message part.
___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
