New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds Tool Specific Toolbar #1586

Merged
merged 11 commits into from Jun 19, 2017

Conversation

Projects
None yet
3 participants
@ketanhwr
Contributor

ketanhwr commented Jun 1, 2017

#1084

@bjorn, @Ablu : I've added a tool specific toolbar. It's not complete right now.

I've added the tools specific to stamp brush and bucket fill tool only, i.e. Flipping and Rotating, and the Random tool as well. I've attached a screenshot as well. The toolbar is visible after the Offset Layer tool. If the selected tool is changed to something else, the tools are not visible anymore.

toolspecific

I will have to extend this only to add specific tools for other tools, so I thought of making this pull request.

Show outdated Hide outdated src/tiled/mapeditor.cpp Outdated
@ketanhwr

This comment has been minimized.

Show comment
Hide comment
@ketanhwr

ketanhwr Jun 2, 2017

Contributor

I'm thinking it would be a better option to make a new class ToolSpecificToolBar. @Ablu what do you think? It could be easily extended that way.

Contributor

ketanhwr commented Jun 2, 2017

I'm thinking it would be a better option to make a new class ToolSpecificToolBar. @Ablu what do you think? It could be easily extended that way.

@Ablu

This comment has been minimized.

Show comment
Hide comment
@Ablu

Ablu Jun 2, 2017

Contributor

I think one option could be to simply create one toolbar for each editing context and then simply toggle the visibility according to the current context. That would be easier to handle regarding deletion and recreation of buttons. Also if later other editing contexts might require something different than a toolbar, or require special toolbars that should be easier since there is no dependency on a toolbar then. But maybe @bjorn should comment on this...

Contributor

Ablu commented Jun 2, 2017

I think one option could be to simply create one toolbar for each editing context and then simply toggle the visibility according to the current context. That would be easier to handle regarding deletion and recreation of buttons. Also if later other editing contexts might require something different than a toolbar, or require special toolbars that should be easier since there is no dependency on a toolbar then. But maybe @bjorn should comment on this...

ketanhwr added some commits Jun 2, 2017

@ketanhwr

This comment has been minimized.

Show comment
Hide comment
@ketanhwr

ketanhwr Jun 2, 2017

Contributor

@Ablu you can have a look.

I also tried the other way round: Basically, I instantiated a QToolButton for each of the tool (Random, Flipping, Rotating) in the constructor of the ToolSpecificToolBar and I added or removed the same instances when the selected tool was changed. But it didn't seem to work. The QToolButton would be visible only for the first time. I guess QToolbar::clear() actually clears the memory too.

So the current implementation is instantiating a new QToolButton every time the selected tool is changed.

Contributor

ketanhwr commented Jun 2, 2017

@Ablu you can have a look.

I also tried the other way round: Basically, I instantiated a QToolButton for each of the tool (Random, Flipping, Rotating) in the constructor of the ToolSpecificToolBar and I added or removed the same instances when the selected tool was changed. But it didn't seem to work. The QToolButton would be visible only for the first time. I guess QToolbar::clear() actually clears the memory too.

So the current implementation is instantiating a new QToolButton every time the selected tool is changed.

@Ablu

This comment has been minimized.

Show comment
Hide comment
@Ablu

Ablu Jun 3, 2017

Contributor

I guess @bjorn has to do this review... I do not have too much experience with QtGui... I still think that having multiple toolbars and only toggling the visibility might be another clean approach... But I do not want to rate them against each other :)

Contributor

Ablu commented Jun 3, 2017

I guess @bjorn has to do this review... I do not have too much experience with QtGui... I still think that having multiple toolbars and only toggling the visibility might be another clean approach... But I do not want to rate them against each other :)

@bjorn

I think in general this is a good start, though eventually populating the tool bar should be left to the tools. A new virtual function would be added in AbstractTool like virtual void populateToolBar(QToolBar* toolBar);, which is called when the tool is selected. Then we'd need to find a good way of sharing common functionality (actions working on the active tile stamp) between the stamp brush and fill tool.

Show outdated Hide outdated src/tiled/mapeditor.cpp Outdated
Show outdated Hide outdated src/tiled/stampbrush.h Outdated
Show outdated Hide outdated src/tiled/toolspecifictoolbar.cpp Outdated
Show outdated Hide outdated src/tiled/toolspecifictoolbar.cpp Outdated
Show outdated Hide outdated src/tiled/toolspecifictoolbar.h Outdated
@ketanhwr

This comment has been minimized.

Show comment
Hide comment
@ketanhwr

ketanhwr Jun 5, 2017

Contributor

Alright so how about this:

  • Add a function virtual void populateToolBar(ToolSpecificToolBar* toolBar) in AbstractTool
  • The ToolSpecificToolBar would hold the QAction instances of all the tools like Flipping/Rotating/etc.
  • Whenever a tool is activated, the populateToolBar would call the functions like addFlippingTools, etc to add the QAction instances to the toolbar.
Contributor

ketanhwr commented Jun 5, 2017

Alright so how about this:

  • Add a function virtual void populateToolBar(ToolSpecificToolBar* toolBar) in AbstractTool
  • The ToolSpecificToolBar would hold the QAction instances of all the tools like Flipping/Rotating/etc.
  • Whenever a tool is activated, the populateToolBar would call the functions like addFlippingTools, etc to add the QAction instances to the toolbar.
@bjorn

This comment has been minimized.

Show comment
Hide comment
@bjorn

bjorn Jun 5, 2017

Owner

That would be a good intermediate step, though eventually I think the parameter should be simply a QToolBar pointer and the QAction instances should be owned by the tools.

Owner

bjorn commented Jun 5, 2017

That would be a good intermediate step, though eventually I think the parameter should be simply a QToolBar pointer and the QAction instances should be owned by the tools.

@ketanhwr

This comment has been minimized.

Show comment
Hide comment
@ketanhwr

ketanhwr Jun 5, 2017

Contributor

So there's no need for an intermediate class ToolSpecificToolBar then, I guess. It can be created in MapEditor only like the other toolbars.

Contributor

ketanhwr commented Jun 5, 2017

So there's no need for an intermediate class ToolSpecificToolBar then, I guess. It can be created in MapEditor only like the other toolbars.

@bjorn

This comment has been minimized.

Show comment
Hide comment
@bjorn

bjorn Jun 5, 2017

Owner

Right, with the important difference, that the content of the tool bar is determined by the currently selected tool.

Owner

bjorn commented Jun 5, 2017

Right, with the important difference, that the content of the tool bar is determined by the currently selected tool.

@ketanhwr

This comment has been minimized.

Show comment
Hide comment
@ketanhwr

ketanhwr Jun 6, 2017

Contributor

Currently, all the functions handling rotation and flipping are in MapEditor class. If these are shifted to StampBrush and BucketFillTool then we won't be able to share common tile stamps. How do I handle this? Should I pass a reference of MapEditor instance to populateToolBar too? In this way, we can connect the QAction to the functions in populateToolBar which solves the problem

Contributor

ketanhwr commented Jun 6, 2017

Currently, all the functions handling rotation and flipping are in MapEditor class. If these are shifted to StampBrush and BucketFillTool then we won't be able to share common tile stamps. How do I handle this? Should I pass a reference of MapEditor instance to populateToolBar too? In this way, we can connect the QAction to the functions in populateToolBar which solves the problem

@bjorn bjorn changed the title from Adds Tool Specific Toolbar - #1084 to Adds Tool Specific Toolbar Jun 8, 2017

@bjorn

This comment has been minimized.

Show comment
Hide comment
@bjorn

bjorn Jun 12, 2017

Owner

Currently, all the functions handling rotation and flipping are in MapEditor class. If these are shifted to StampBrush and BucketFillTool then we won't be able to share common tile stamps. How do I handle this? Should I pass a reference of MapEditor instance to populateToolBar too? In this way, we can connect the QAction to the functions in populateToolBar which solves the problem

You do not not need to use MapEditor directly to share the same stamp between these tools. Instead, you could rely on a connection like this one:

connect(mStampBrush, &StampBrush::stampCaptured, this, &MapEditor::setStamp);

So when the StampBrush flips the stamp, it could also emit stampCaptured (which could probably be renamed to stampChanged), and a similar signal can be added to BucketFillTool.

Owner

bjorn commented Jun 12, 2017

Currently, all the functions handling rotation and flipping are in MapEditor class. If these are shifted to StampBrush and BucketFillTool then we won't be able to share common tile stamps. How do I handle this? Should I pass a reference of MapEditor instance to populateToolBar too? In this way, we can connect the QAction to the functions in populateToolBar which solves the problem

You do not not need to use MapEditor directly to share the same stamp between these tools. Instead, you could rely on a connection like this one:

connect(mStampBrush, &StampBrush::stampCaptured, this, &MapEditor::setStamp);

So when the StampBrush flips the stamp, it could also emit stampCaptured (which could probably be renamed to stampChanged), and a similar signal can be added to BucketFillTool.

@ketanhwr

This comment has been minimized.

Show comment
Hide comment
@ketanhwr

ketanhwr Jun 19, 2017

Contributor

@bjorn, I've added a new class StampActions. I first started with AbstractStampTool class but there was nothing common except the newly added QActions so I reverted and made the class StampActions.

Contributor

ketanhwr commented Jun 19, 2017

@bjorn, I've added a new class StampActions. I first started with AbstractStampTool class but there was nothing common except the newly added QActions so I reverted and made the class StampActions.

@bjorn

Hmm, at least mStamp and mRandom would be still in common, and when moved to the StampActions class would avoid more duplicated code. Let me know how you feel about that.

Show outdated Hide outdated src/tiled/stampactions.cpp Outdated
Show outdated Hide outdated src/tiled/stampactions.h Outdated
Show outdated Hide outdated src/tiled/bucketfilltool.h Outdated
Show outdated Hide outdated src/tiled/stampbrush.h Outdated

@bjorn bjorn merged commit 43b9da9 into bjorn:master Jun 19, 2017

0 of 2 checks passed

continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
@bjorn

This comment has been minimized.

Show comment
Hide comment
@bjorn

bjorn Jun 19, 2017

Owner

Thanks! I'm looking forward to see the use of this toolbar extended to more tools. :-)

Owner

bjorn commented Jun 19, 2017

Thanks! I'm looking forward to see the use of this toolbar extended to more tools. :-)

boaromayo added a commit to boaromayo/tiled that referenced this pull request Jun 28, 2017

Update forked repo (#1)
* Fixed crash when editing collision when tile image wasn't loaded

When opening a tileset it can happen that the tileset image fails to
load. In this case, opening the tile collision editor could lead to a
crash.

* GmxPlugin: Fixed tile type inheritance for tile objects

Now tile objects of which the tile has a type defined are exported as
instances of this type of object in the GameMaker room file.

* Added toolbar for stamp brush and bucket fill tool (bjorn#1586)

This adds a new tool-specific toolbar that can be used by tools.

Currently contains actions for rotating/flipping stamp and toggling random mode.

Closes bjorn#1084

* docs: Fixed link to other page

* QtPropertyBrowser: Removed deprecation warnings

The classes were deprecated in Qt 5.0 and warnings have been added in Qt
5.7.

* Fixed rendering of tile object outlines for resized objects

They were taking the size of the image instead of the size of the
object, which means this was broken since Tiled 0.12.

* Fixed rendering of tile objects when the image couldn't be loaded

If the tile was found but its image failed to load, tile objects would
not render at all and due to a broken boundingRect be also impossible to
interact with.

Now they render as the special "missing image marker" and can be
interacted with.

* More fixes for labels of objects nested in a group layer

* Fixed labels shown on objects hidden via a group layer
* Fixed updating of label visibility when toggling group layer visibility

* Fixed updating of label positions when moving a group layer

When moving a group layer, any labels present for objects nested within
that group layer need to be synchronized.

* GmxPlugin: Added support for defining views with objects (bjorn#1621)

* Fixed hang when trying to fill with a pasted stamp

Since 688ec7d the size of a copied map
is set to 0x0 instead of matching the tile layer's size. It was supposed
to be irrelevant, but as it turns out TileStamp::maxSize was based on
the size of the map instead of the size of the tile layer. This could
lead to an infinite loop in fillWithStamp in bucketfilltool.cpp.

Closes bjorn#1617
Closes bjorn#1624

* Restored Ctrl+N shortcut on "New Map" action

There isn't really a good reason not to have this shortcut. Eventually
it may pop up a dialog where you can pick what you want to create, but
since it's more common to create new maps than new tilesets we can just
do that for now.

* Use initializer list for quick-stamp keys

* Introduced TilesetDocumentsModel and its sort-filter model companion

This model lists the tileset documents that are currently open, and the
sort-filter version sorts them by name and filters out tilesets that are
embedded in other maps than the current one.

This model extracts part of the logic from TilesetDock, so that it could
be reused by an updated TerrainModel. The TerrainModel currently only
lists terrains from tilesets that are already part of the map, but it
should display all loaded external tilesets.

* libtiled-java: Fixed wrong exception being caught in TileSet (bjorn#1629)

* Display all tilesets with terrain in the Terrains view

Except for tilesets that are embedded into another map than the current
one, the Terrains view now displays all tilesets that have terrains
defined.

The Terrain Brush will now automatically add the tileset of the
currently selected terrain to the map when it isn't already present.

* Show custom properties on tiles and terrains in the map editor

While still not editable, this change shows these properties in a
read-only fashion. It is often useful to see them, as indicated by
multiple users on the forum.

* Bumped version to 1.0.2 and updated NEWS file

* Adds option to lock/unlock layer (bjorn#1627)

Locking a layer prevents modifications to the layer by the tools, as
well as by some actions like cut and delete. Modifications to objects
are prevented by making them not selectable.

Closes bjorn#734

* Fixed tool tips on flipping and rotating stamp actions

@boaromayo boaromayo referenced this pull request Aug 3, 2017

Closed

Update forked repo (#1) #1675

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment