kicad-developers team mailing list archive

[timofonic timofonic <timofonic@xxxxxxxxx>]

Hello.

I'm not a developer at all, but I got curious about this.

KiCad is 500KLOC and 80% of it is about GUI, right? Would rewriting dialog
code by hand require to change a lot of code too? Would it reduce LOC?

I see Libreoffice has some kind of similar issue, but the situation is even
worse. It seems to have 864,463 LOC and features their own toolkit named
VCL (20 years old and it seems to be quite outdated by today's standards
too). They would prefer to migrate to something like Qt or Gtk, but the
code is very rooted in the codebase and the required rewrite isn't an easy
task to do at all.

Other projects such as QUCS already use Qt.

I just hope the best future proof solution gets chosen, I really have high
hopes in KiCad becoming "the GCC of hardware" as CERN said.

Regards.
On Aug 17, 2015 7:26 PM, "Wayne Stambaugh" <stambaughw@xxxxxxxxx> wrote:

> On 8/17/2015 9:14 AM, David Novak wrote:
> >> To be honest, I've never been a big fan of dialog box layout tools.
> >> Their strength is there weakness.  They promote designing quick dialog
> >> box layouts that makes reuse difficult.  Take a look at the padding and
> >> overall layout in KiCad's dialogs.  They are all over the map.  I prefer
> >> hand coding dialogs.  It's painfully slow but encourages reuse (well
> >> designed base dialog classes) and standardization (using wxSizerFlags).
> >
> > I agree with Wayne. Dialog layout tools are nice to get up and running
> > quickly, but the more I use them, the more they get in the way. On
> > internal projects, my team ends up implementing workarounds for advanced
> > features.
> >
> > I've recently started trying to convince my team to code the dialogs by
> > hand. In my mind, with a little planning up front, hand coding the
> > dialog could be relatively quick.
> >
> > David
> >
>
> Thanks for the vote of confidence.  I thought I was the lone voice in
> the woods when it came to hand coding dialogs.  I doubt we will have an
> easy time convincing everyone else it's a good idea.  That being said,
> we may end up in a position where we have no option if there is not a
> viable open source option.  I would reject using a proprietary tool and
> I don't want to waste precious KiCad development resources maintaining
> wxFormBuilder.
>
> >
> > On 8/13/2015 2:41 PM, Wayne Stambaugh wrote:
> >>
> >> On 8/13/2015 2:05 PM, jp charras wrote:
> >>> Le 13/08/2015 18:36, Eldar Khayrullin a écrit :
> >>>> Hi all.
> >>>> Maybe in future need to port kicad in other modern gui as qt(
> >>>> https://en.wikipedia.org/wiki/Qt_(software) )
> >>> A bit overkilled for this issue (if this is an issue).
> >>> I am not especially thrilled by QT.
> >>> This is a very good tool, but it has its own issues.
> >>> Good luck to volunteers who will port 400 000 lines of code relative
> >>> to GUI.
> >>> (80% of code of any application; Kicad has more than 500 000 lines of
> >>> code)
> >> We'll leave that decision to the next project manager.  This project
> >> manager is not interested porting KiCad to QT.  This has been discussed
> >> before.
> >>
> >>>> 13.08.2015 13:00, Blair Bonnett пишет:
> >>>>> Hi all,
> >>>>>
> >>>>> It appears wxFormBuilder is, if not dead, not far from it. The
> >>>>> evidence:
> >>>>>
> >>>>> * No stable release in 4 years, and the last beta release was 13
> >>>>> months ago.
> >>> Although I agree with the fact wxFormBuilder is not actively
> maintained,
> >>> the last release was made the 17 June.
> >>>
> >>> I share your concern about wxFormBuilder.
> >>>
> >>> But replacing it is not easy.
> >>>
> >>> To answer one of your questions, before using wxFormBuilder, I used
> >>> DialogBox (free version).
> >> I'm reluctant to use proprietary tools for all of the usual reasons.  I
> >> would rather code dialogs by hand than use a proprietary tool.
> >>
> >>> It worked fine and was easy to use.
> >>> It is written and maintained by the creator of wxWidgets.
> >>>
> >>> But the user code is embedded in automatically generated DialogBox.
> >>> I did not used recent versions, so it is perhaps now different.
> >>>
> >>> One on the *best features* of wxFormBuilder is the fact it creates
> >>> "black box" files and all the user code is in other files.
> >>> You even do not need to read them.
> >>>
> >>> Any other candidate should have this feature.
> >>>
> >>> We need volunteers to test other candidates (in fact a very few
> >>> candidates)
> >> To be honest, I've never been a big fan of dialog box layout tools.
> >> Their strength is there weakness.  They promote designing quick dialog
> >> box layouts that makes reuse difficult.  Take a look at the padding and
> >> overall layout in KiCad's dialogs.  They are all over the map.  I prefer
> >> hand coding dialogs.  It's painfully slow but encourages reuse (well
> >> designed base dialog classes) and standardization (using wxSizerFlags).
> >>   I got shot down the last time I suggested this and I understand the
> >> reasoning.
> >>
> >>>
> >>>>> * A grand total of 13 commits in the last 12 months (current trunk is
> >>>>> r2205, r2192 was made on 1 August 2014). A number of these are
> >>>>> buildsystem / release / changelog (!) updates.
> >>>>> * No developer responses on the mailing list, including to a message
> >>>>> three months ago [1] asking if the project was still active.
> >>>>> * No support for newer widgets. For example, the wxSpinCtrlDouble
> >>>>> widget added in wxWidgets 2.9.0 is not supported. I patched it to add
> >>>>> this widget back in April and posted the patch to both the mailing
> >>>>> list and an existing ticket from three years ago [2]. No response to
> >>>>> that either.
> >>>>>
> >>>>> We may have to start thinking about whether we continue with it from
> >>>>> here, or consider a move towards a different tool.
> >>>>>
> >>>>> I realise any change like this isn't going to happen prior to the
> >>>>> stable release, and nor am I suggesting it should. But with the
> recent
> >>>>> post to this list about UI improvements, I think this is a highly
> >>>>> related topic which should be discussed as well.
> >>>>>
> >>>>> There are a number of alternatives listed on the wxWidgets wiki [3].
> >>>>> Does anybody have any experience with any of them? (Spoiler alert, I
> >>>>> don't). Are there any thoughts on how to proceed from here?
> >>>>>
> >>>>> Regards
> >>>>> Blair
> >>>>>
> >>>>>
> >>>>> [1]
> https://sourceforge.net/p/wxformbuilder/mailman/message/34100789/
> >>>>> [2] https://sourceforge.net/p/wxformbuilder/feature-requests/45/
> >>>>> [3]
> >>>>>
> https://wiki.wxwidgets.org/Tools#Rapid_Application_Development_.2F_GUI_Builders
> >>>>>
> >>>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>