new toolbars

The individual toolbars, category toolbar and custom toolbar are ready...ish.
I haven't really considered a default layout for all the individual new toolbars.
One possibility is to just have them hidden by default.

The toolbar/dockwidget context menu is over-populated now,
I've been considering reimplementing http://doc.qt.io/qt-5/qmainwindow.html#createPopupMenu
and putting the new individual toolbars in a submenu.

You can see the majority of the changes in:
void QC_ApplicationWindow::menus_and_toolbars()
lc_actionfactory
lc_customtoolbar

It's in the toolbar_merging branch (I did one merge a few weeks ago).

Custom toolbar:
1. make a txt file
2. start librecad
3. in application preferences choose the txt file you made
4. restart librecad

You can press F2 (arbitrary hotkey) to add or remove the most recent triggered action to the custom toolbar.
You can rearrange the icons by editing the file; and you can add a separator by adding a line with a hyphen.
Here is my custom toolbar:

DrawCircle
DrawCircle2P
DrawCircle3P
DrawCircleTan2_1P
DrawCircleTan1_2P
DrawCircleTan3
-
DrawLine
DrawLineHorizontal
DrawLineVertical
DrawLineParallelThrough
DrawLineBisector
DrawLineTangent1
DrawLineTangent2
DrawLineOrthogonal
DrawLinePolygonCenCor
DrawLinePolygonCorCor
-
ModifyMoveRotate
ModifyMirror

The names are those found in rs.h (minus the "Action" prefix).
action_list.txt

I've been considering making dockwidget alternatives to the toolbars, with maybe 4-6 columns of icons.
I've also been considering to-b's idea of grouping line tools and their options in one dockwidget,
and likewise for the other categories.
This could be the solution to the user awareness problem regarding the options toolbar.

I've lost some of my motivation because of the persistence of the tangent point issue,
and also because I'd prefer working on "the cutting edge" (LC3) rather than the obsolescent.
Right now I'm focused on my flow chart creator.

Let me know how you want to proceed.

looks great!

I'm not a GUI expert, but I will still try to suggest something.

as previous discussed, monitors are likely nowadays to be wide, but not tall (quite often to see dual monitors, 3840x1080, with dual 1080p), better to waste left/right, and save on top/left toolbar areas;

have to do something for the option toolbars (like the box to input radius when drawing circles by center and radius), users keep complaining that they couldn't be located easily.

Anyway, good work!

Yes dockwidget sidebars seem preferable.

Here is my idea for a sidebar where every category is a dockwidget,
which can be removed or rearranged.



What do you think about adding the two spline tools to the line category?

What do you think about a tool options dock widget where the layer list is?

Hi ravas,

this seems to be better.

I'm thinking about using more tabs in one row, by using icons instead of text which is longer, for example:

line, circle/arc, ellipse, spline, polyline, text, point

if one row is limited to 5 icons

line, polyline, circle/arc, ellipse, text

spline, point

I suppose most people will be using the first row more often.

I think we don't have to separate circle/arc, just as ellipse/elliptical arc are grouped together.

Another question, concerning the icon size on HD displays, can we use font size based icon sizes? looks like we don't have text size issues on HD. if there's a way of using the "em" size unit, instead of pixels.

ravas wrote

Here is my idea for a sidebar where every category is a dockwidget,
which can be removed or rearranged.



What do you think about adding the two spline tools to the line category?

What do you think about a tool options dock widget where the layer list is?

The automatic tab feature of dockwidgets does not support icons as far as I know.
Text labeled tabs are easier to differentiate anyhow... it would be a sea of icons otherwise.

The design idea is to expose and keep exposed exactly what a user wants.
Switching tabs would ideally not happen often.
However, the dockwidgets can be arranged however the user wants.

I'm not opposed to merging the circle/arc categories.

A whole dockwidget for two spline tools and one point tool seems excessive to me.
I would just add the splines to the line category and use the misc toolbar shown at the bottom of the image.

Using em for the icon size seems confusing to me.

With the new individual toolbars, category toolbar, custom toolbar and these dockwidgets
there is an abundance of possibilities.

I want to merge soon, so that users can try the various possibilities,
and so that you and other developers can try modification ideas.

I didn't work enough on this part to make a call here. I didn't notice anything against merging.

If you think it's stable enough, try a pull request. If you are not sure about the stability, you may consider "git merge --squash", so the merge can be easily reverted.

ravas wrote

The automatic tab feature of dockwidgets does not support icons as far as I know.
Text labeled tabs are easier to differentiate anyhow... it would be a sea of icons otherwise.

The design idea is to expose and keep exposed exactly what a user wants.
Switching tabs would ideally not happen often.
However, the dockwidgets can be arranged however the user wants.

I'm not opposed to merging the circle/arc categories.

A whole dockwidget for two spline tools and one point tool seems excessive to me.
I would just add the splines to the line category and use the misc toolbar shown at the bottom of the image.

Using em for the icon size seems confusing to me.

With the new individual toolbars, category toolbar, custom toolbar and these dockwidgets
there is an abundance of possibilities.

I want to merge soon, so that users can try the various possibilities,
and so that you and other developers can try modification ideas.

What do you think about a "curve" category?
It could contain the free hand line, splines and arcs (bezier if implemented).

Some ideas on how to simplify / organize:

- remove the two delete actions from the modify menu
- add delete selected to the edit menu
- remove "circle inscribed" in favor of "tangential 3 circles"
- remove concentric arc, concentric circle and parallel line in favor of modify→offset

It's your domain.

I tend to avoid deletion of any user visible features, but a clean and logic GUI is important for 2.1. At least, compulsive hoarding requires treatment.
 

ravas wrote

Some ideas on how to simplify / organize:

- remove the two delete actions from the modify menu
- add delete selected to the edit menu
- remove "circle inscribed" in favor of "tangential 3 circles"
- remove concentric arc, concentric circle and parallel line in favor of modify→offset

I just did another pre-merge and fixed mergetool errors:
https://github.com/r-a-v-a-s/LibreCAD/tree/gui_update

I did setup a new default layout:


People will need to use clear settings "all" or "layout" in application preferences to see this layout.

I moved the command line to the right because of the complaints of not enough vertical drawing area.
The one issue is that the command line prompt messages change the width of the widget.
The only alternative I thought of was to have the prompt messages display in the commandline output.
I have not done anything about it yet.

One other issue is action forward-stepping and back-stepping.

Forward-stepping seems to be tied into the cad toolbar via forceNext.
The solution for users is to simply select objects first, and then activate the tool.
The hatch action had to be switched to ActionDrawHatchNoSelect.

Back-stepping has simply been bypassed.
I'm skeptical of the usefulness of this feature... does anyone use it? If so, what's the use case?
I might be able to think of a superior solution if someone has a use case.
As I have said before, it overloads right-click and makes the button inconsistent.
Being able to exit the action and get back to the selection tool in a consistent manner seems more useful to me.
If nothing else, I recommend a different hotkey, such as Ctrl+Right-click.

I didn't delete any of the cad toolbar files or related code.
Tell me if and when you want me to do that.

I'll prepare an announcement summarizing the changes.

Some issues:

what about the "Select ToolBars": Looks like the only way to use "Modify->Move" is by selecting entities before Modify->Move

The mainwindow has height larger than 1080, and I can not resize it to smaller, therefore, can not see the command widget

The CAD toolbar should shrink to to fit the icon size on opening.

ravas wrote

I didn't delete any of the cad toolbar files or related code.
Tell me if and when you want me to do that.

I'll prepare an announcement summarizing the changes.

I can shrink the mainwindow after closing of the "line", "modify" CAD toolbars.

Couldn't find a way to restore the line/modify CAD toolbars.

Yes that's what I was referring to by the forward-stepping issue.
Take a look at:

/**
 * Goes one step further in the current action.
 */
void QC_ApplicationWindow::slotEnter() {
    RS_DEBUG->print("QC_ApplicationWindow::slotEnter(): begin\n");
// if (cadToolBar) {
//            cadToolBar->forceNext();
//        } else {
            RS_GraphicView* graphicView = getGraphicView();
            if (graphicView) {
                graphicView->enter();
            }
//        }
//    }
    RS_DEBUG->print("QC_ApplicationWindow::slotEnter(): end\n");
}

We will need to figure out an alternative to forceNext if we want the other behavior... I think.

--

Larger than 1080? hmm... this might be an issue of old settings.
There is plenty of room for the commandline at the bottom for me on 1080 (screen shot?).
Although the new default layout doesn't include it at the bottom.
Try the Layout button in application preferences -> defaults... then restart LC.
I'm not sure of how else to handle the old settings.

You can restore the line/modify dockwidgets with the toolbar/dockwidget context menu.
I'll add them to the dockwidget menu on the menubar.

Just figured out that the context menu is only available over toolbar times, not over the toolbar buttons.

ravas wrote

You can restore the line/modify dockwidgets with the toolbar/dockwidget context menu.
I'll add them to the dockwidget menu on the menubar.

/**
 * Called from the application.
 */
void QG_CadToolBar::forceNext() {
    if(activeToolbars.size()==0) return;
        auto p=activeToolbars.back();
        if (p && p->rtti() == RS2::ToolBarSelect)
                p->runNextAction();
}

void QG_CadToolBarSelect::runNextAction() {
        if (selectAction) {
        if(selectAction->rtti() == RS2::ActionSelect){
            //refuse to run next action if no entity is selected, to avoid segfault by action upon empty selection
            //issue#235
            if( static_cast<RS_ActionSelect*>(selectAction)->countSelected()==0) return;
        }
        selectAction->finish();
                selectAction = nullptr;
    }
    if (nextAction!=-1) {
        actionHandler->killSelectActions();
        actionHandler->setCurrentAction((RS2::ActionType)nextAction);
    }
}

void QG_CadToolBar::showToolBarSelect(RS_ActionInterface* selectAction,
                                      int nextAction) {
        auto p=m_toolbars[RS2::ToolBarSelect];

        p->setNextAction(nextAction);
        p->setSelectAction(selectAction);
    showToolBar(RS2::ToolBarSelect);
        showSubToolBar();
}

/**
 * Shows the select toolbar with the given action to launch.
 */
void QG_DialogFactory::requestToolBarSelect(RS_ActionInterface* selectAction,
        RS2::ActionType nextAction) {
        if (cadToolBar) {
        cadToolBar->showToolBarSelect(selectAction, nextAction);
    }
}

void RS_ActionSelect::updateToolBar() {
    if (RS_DIALOGFACTORY) {
        if (isFinished()){
            if(container->countSelected()==0){
                //some nextAction segfault with empty selection
                //todo: make actions safe with empty selection, issue#235
                RS_DIALOGFACTORY->commandMessage(tr("No entity selected!"));
                //do not keep toolbar select after this action finishes, issue#291
//                RS_DIALOGFACTORY->requestToolBarSelect(this, nextAction);
                RS_DIALOGFACTORY->requestPreviousToolBar();
            } else{
                if ( entityTypeList.size()){
                    //only select entity types from the given list
                    //fixme, need to handle resolution level

                                        for(auto e: *container){
                                                if (e && e->isSelected()) {
                                                        if(!entityTypeList.count(e->rtti()))
                                                                e->setSelected(false);
                        }
                    }
                }
                RS_DIALOGFACTORY->requestPreviousToolBar();
            }
        }else{
            RS_DIALOGFACTORY->requestToolBarSelect(this, nextAction);
        }

    }
}

wow... so complicated... @_@

Let me know if you can come up with a solution...

I requested access to the announcement section a few days ago. No change yet.
Do you want me to post about this update?

Hi ravas,

I thought I added permissions for you.

Maybe, I made a mistake here. :(

sorry :(

ravas wrote

I requested access to the announcement section a few days ago. No change yet.
Do you want me to post about this update?