Slashdot Mirror


Ask Slashdot: Linux Database GUI Application Development?

New submitter msubieta writes I have been developing some applications to use in small businesses using Windows and SQL Server. I would like to move on and start doing the same thing in Linux. I have looked at several Frameworks/Databases/Development environments and I really don't know what is the best/simplest/fastest to learn approach. I use VS and C# mostly, although I could easily go back to C++. I found Qt and GTK+ are the most common frameworks, but they seem to lack controls that deal with datasets and stuff (sorry, spoiled by the .net form controls), but I also know that I could use Mono in order to make the jump. I would have no problem on moving to MySQL, as I have done quite a lot of work on that side, and I would like to stick with the traditional client server application, as I find it easier to maintain, and a whole lot more robust when it comes to user interaction (web apps for POS applications don't seem to be the right way to go in my view). Any suggestions/comments/recommendations?

15 of 264 comments (clear)

  1. Lazarus by Tablizer · · Score: 5, Interesting

    Look into the Lazarus project. It's a Delphi semi-clone.

  2. Biased, but... by tyroneking · · Score: 4, Informative

    I'm biased towards Python - and the following suggestions have nice UIs but they are web-based - so please forgive me in advance ;)

    After years working in Siebel (UI dev tools, transparent database interface, etc) moved over to Linux dev and was stuck for a while - finally settled on Flask (http://flask.pocoo.org/) a Python micro-framework, which is light (i.e. not as incomprehensible as Django ;) but comes with a lot of functionality if you need it. Jump in. Here's a good guide that mixes in Bootstrap to make a very appealing UI - http://flaskbook.com/

    Alternatively, go all ERP with lots of built in business functionality and nice UI features and try ERP Next (https://erpnext.com/) - which I'm looking at right now. It has some poor documentation, but the dev guide for the underlying framework (Frappe) is pretty clear (e.g. https://frappe.io/developers/g...) and looks less scary.

  3. I'd consider Go and PostgreSQL by MillerHighLife21 · · Score: 4, Informative

    Go is still young so if you're looking from a "language saturation" standpoint, it's not where you want it to be yet but it's gaining traction fast. It will be familiar from a typing standpoint and as a language it provides excellent concurrency, which in certain types of applications becomes a really big help. By learning Go you'd be providing yourself with a language that helps solve a complicated use case rather than just another language that does exactly the same things as other server side languages. It's compile time is almost instantaneous which is similar to a scripting language. Runs well on both Windows and non-Windows environments too, which will make it easier to use it along side your existing .NET stuff if needed.

    PostgreSQL as a database is pretty much amazing. Everything you like from SQL Server is there without a lot of the stuff that you don't. Here's a writeup that I did a few months back breaking down what's great about PostgreSQL in as concise of a post as I could. http://www.brightball.com/post...

    Since this is a specific "what should I learn based on my current background" type question, that's my recommendation for YOU based on the post.

    --
    "Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
    1. Re:I'd consider Go and PostgreSQL by greg1104 · · Score: 4, Informative

      That's a nice outline of Postgres features; small and very pedantic correction for you. CREATE INDEX CONCURRENTLY in PostgreSQL isn't really asynchronous, since the client running it is stuck there waiting for it. And it does still need a full table lock to complete. It just only needs that for a brief moment in most cases, to install the index when it's built. But that's not guaranteed. I added a caveat to the docs a version or two ago that warns about the bad case; see building indexes concurrently, in particular the bit starting with "Any transaction active when the second table scan starts..." It's really rare that happens, but if you have long-running transactions eventually you'll run into it painfully.

      I would restate the situation as "You can even create indexes with minimal locking of large tables when a new index is added". The code can't quite avoid locks altogether and remain transaction safe.

  4. You're picking your tool before your problem. by davidsheckler · · Score: 4, Insightful

    FIrst decide the right way to solve the problem, then look at the available tools to solve it.

    Client server is better at solving specific problems, anything graphics heavy usually. For pure data entry a straight up server side web application is usually the best choice. You don't need to support multiple client installs, just the server instance.

    For ease of development: PHP, for scalability, some java based framework (Spring, Wicket, etc...) or even Scala/Play if you feel somewhat daring.

    1. Re:You're picking your tool before your problem. by DickBreath · · Score: 5, Funny

      When the only hammer you have is C++, every problem begins to look like a thumb.

      --

      I'll see your senator, and I'll raise you two judges.
  5. Heresy Alert by Jawnn · · Score: 5, Interesting

    I'm going to get jumped for saying this, but stick with Windows for fat client development. Unless you are looking at developing web apps, you are going to be almost completely disappointed at the selection of tools available to you on Linux when compared to those for Windows. I'm not saying that there aren't tools for doing this on Linux, but dear gawd, why would you want to when the VS tools are so much easier to work with. And by "work with" I mean get work done. Use MySQL on Linux as your db server, by all means, but do your client development with what you already know.

  6. Re:GUI Datasets by Richard_at_work · · Score: 5, Informative

    You might want to take a longer look at C# because there is no reason you can't just use Entity Framework to do exactly what you find it easier to do - create the model, creates readers and writers, abstract the database stuff away and just get to use plain C# objects, lists, collections and other things instead of cumbersome DataTables or Datasets etc.

  7. Re:Not a joke, Microsoft is open sourcing good bit by Anonymous Coward · · Score: 4, Informative

    We're looking at 2 years minimum for .Net Core to be solid and complete for Linux. I've been following this closely. Tools are totally missing as well, which you mentioned. I don't see something like Visual Studio even being ported unless MS abandons the "Windows is dominant" position. If they do, I don't expect a solid showing for VS until 2020 at the earliest. For now you are stuck with Mono, which isn't bad, it's just anemic compared to VS.

  8. Rule #1 of development: Know your requirements. by RingDev · · Score: 4, Insightful

    If you're just developing for the fun of it, have at.

    But if your goal is to have a POS application, stop writing code right now. There exist hundreds of off the shelf POS apps all ready. For Windows, for Linux, thick clients, thin clients, web, desktop, green screen, etc...

    Your time would be vastly better spent finding an existing product and adapting your business process to it. Especially if it is something that can tie into your accounting/inventory systems.

    As the old saying goes, "Good developers write good code, great developers steal good code."

    -Rick

    --
    "Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
    1. Re:Rule #1 of development: Know your requirements. by TechyImmigrant · · Score: 5, Interesting

      >But if your goal is to have a POS application, stop writing code right now. There exist hundreds of off the shelf POS apps all ready. For Windows, for Linux, thick clients, thin clients, web, desktop, green screen, etc...

      And they are all shit.
      So I wrote my own. It's not shit. The staff tell me it's not shit.

      POSs are shit because they have to attend to the general case, whereas each store is a special case. I our case, there is nothing that comes close to addressing the particular needs of a yarn store (SKUd and non SKUd goods, hand made goods, goods my weight and/or volume, consignment goods, classes, group sessions etc). Go into a yarn store and see if they check you out by slowly clicking and typing at some horrible POS, they usually do.

      If you took my POS and put it in a hardware store, it would be shit.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  9. Re:Hakija by jedidiah · · Score: 5, Insightful

    You couldn't be more wrong if you tried.

    If you're willing to explore something other than what Microsoft has spoon fed you, there's more than enough shiny happy development interfaces out there.

    --
    A Pirate and a Puritan look the same on a balance sheet.
  10. Qt + C++ by ClayDowling · · Score: 4, Informative

    I'll recommend Qt and C++ as a workable combo. Learn how to use their Model/View architecture and there's a whole lot of fun stuff that opens up for you. Instead of looking for database components, think in terms of writing a data model that happens to get its data from an SQL backend.

    I'll also second the recomendation of others to look at PostgreSQL for your backend. When it comes time to deploy your application, PostgreSQL is a lot easier to package and install than SQL Server. The features aren't identical, but they're close enough for all but some very specialized cases. In a lot of those cases, there are tools that accomplish the same goals via a different mechanism.

  11. Re:Java by AqD · · Score: 5, Insightful

    How about Java FX 8?

    Being actually using it for half of a year. It's a significant improvement over Swing and definitely superior to winform or GTK#, not so over WPF.

    A few problems with it:

    • * The data-binding/observable mechanism isn't directly compatible with old Java beans. The mechanism is the only reason I choose JavaFX. It also requires some learning and adaption to get used to the programming style but definitely worth it.
    • * Toolset is incomplete and you wouldn't even find any IDE with proper FXML support
    • * Documentation isn't too good and you'd need to read source code instead. The code is quite readable though.
    • * Lacks some basic controls (dialogs will be in next release) and you'd need 3rd-party libraries from the start (ex: ControlsFX).
    • * Loading complex UI takes time, as can be seen from their own demo Modena. Instead of constructing everything at once (as can be done in Qt or WPF without problem), you might need to manually lazy-load parts.
    • * Be careful of weak references/events used everywhere in JavaFX. Things could be GC'ed when you don't think they're supposed to be.
    • * Oracle deprecated the fluent builders API in v8. I recreated the generator and the API here JXTN which is also customizable
    • * It cannot embed native controls/widgets, though it can be embedded into others such as Eclipse RCP/SWT, as what I'm doing now.

    .
    .
    I don't think you'd find a better cross-platform choice. However it'd be very unsuitable for tighter integration with Linux desktop (notifications/WM/process/shell controls etc).

  12. Re:Hakija by Anonymous Coward · · Score: 5, Interesting

    Yup. I develop on Microsoft, Linux, and OS X, and anyone who thinks there are better IDEs than VS are fucking delusional. There's a reason I charge a hell of a lot more to develop on Linux and OS X vs on a MS platform.